Evidently enough, we haven't tried developing on Windows yet :D

Thanks for the report. We do plan on supporting Windows, so this is helpful.

In the short term, I found a work around: checkout the code in WSL and point IntelliJ at it:

https://www.jetbrains.com/help/idea/how-to-use-wsl-development-environment-in-product.html

I am re-purposing this issue to track Pkl support for Windows, and pointing other issues to this one.

Is it possible to build native executables on windows as of now?

A great first step would be to fix the Git clone issues. They block all other work/contributions.

I updated the description of the issue to reflect the broader scope that as been assigned to this issue. I don't know know how issue editing permissions work in GitHub, so feel free to update the issue description as you see fit. Or close this in favor an issue that the maintainers of this project control if that is more convenient.

Is it possible to build native executables on windows as of now?

It is not actively supported. @translatenix makes a valid point about cloning needing to be fixed first. Native executables are part of "done" for this issue.

Extending the above comments about WSL, you can simply type bash in PowerShell to put your current terminal instance into a WSL bash shell. It's what I have been doing to test this on Windows. Saves faffing about with cd 🤣

Some additional items to add to this:

• Paths on windows are not case sensitive but things like internal whitelisting checks are. AKA --allowed-modules file:///c:/myPath/to/Something will fail when it expects a capital drive letter --allowed-modules file:///C:/myPath/to/Something will work
• backslash paths explode, windows allows forward slash paths too though so can work around
• Windows absolute paths fail as file:// is not appended as it is for linux paths, calling with "c:/myPath/to/Something/test.pkl" when adding "c:/myPath/to/Something" will fail with "MalformedURLException: unknown protocol: c"
• /myPath/to/Something is transformed into: file:///myPath/to/Something ; ./myPath/to/Something is transformed to file:///C:/myPath/to/Something ; c:/myPath/to/Something just fails (per above) ; file:///c:/myPath/To/Something will work, but is not whitelisted by either of file:///myPath/to/Something / file:///C:/myPath/to/Something there is https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlea which will return the full final path to the handle opened it will return it like FinalPath: \\?\C:\myPath but that is easy enough to translate to file:/// form.

Please fix this. I want to try to mess around with Pkl but only own a windows machine.

@Ai-N3rd my PR #241 or #237 include details on how to acquire and use the java version of PKL on windows. Not the most convenient given some of the above but it certainly works.