-
Notifications
You must be signed in to change notification settings - Fork 259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support cloning the project on Windows #99
Comments
Is there a timeline to fix this? Developing on WSL is really painful. Gradle and esp. IntelliJ are extremely slow (30s pause is normal), and important IntelliJ features such as showing the JDK source code don't work. |
@bioball Windows support is very important to me. I'd be willing to work on this first step, but I'd need some guidance wrt. changing the cache file layout. |
How about we precent-encode them? According to their docs, these characters are reserved:
Forward slash is also reserved on macOS and Linux, so we don't need to worry about encoding them (Pkl filenames cannot contain forward slashes, and URI forward slashes are equated to path separators). For Windows only, it probably makes sense to percent-encode all other characters. Or, are there other encodings that people use? Here's some literature: https://stackoverflow.com/questions/1184176/how-can-i-safely-encode-a-string-in-java-to-use-as-a-filename I think we'd want to take the same approach for writing output files. For instance, what will be written when you
|
Don't we want the exact same layout across operating systems? Seems desirable for portability/tooling/etc. |
I can see wanting that, especially if you are using the cache dir as a way to vendor dependencies in a repo. In that case, it might make more sense to think of this as a separate problem from writing file paths with In that case, maybe it makes the most sense to always percent encode those characters when writing to the cache dir. |
Is mangling required for -o/-m? Can’t |
What does Windows do right now if you try to create a filename with a reserved character? E.g. if you do Note: for percent-encoding, we will also need to percent-encode the literal |
PowerShell:
Java 21:
File explorer: |
I assume the package URL -> file path conversion should be unique, to rule out name collisions. Should it also be reversible? |
Yeah, ideally reversible, which is why percent-encoding seems like a good choice here. |
To note, the colon here is only kind of an invalid character. Really what you are doing is writing to alternate data streams. This is why the file can appear but is 'empty'. For details: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c54dec26-1551-4d3a-a0ea-4fa40f848eb3 This is just one character but will be slightly different than other path characters that are truly invalid (in terms of if/what errors thrown). Also why from a command line this works:
|
Hm... this impacts pkldoc too. This means that generated pkldoc websites should also use percent encoding, otherwise we can't write directories or filenames onto Windows. @mitchcapper good to know. I don't think that changes the fact that we should encode these characters. |
Right, should certainly not be on the whitelist as not valid as path only some apis for the alt stream access. |
WRT encoding:
Using percent-encoding is pretty ugly, because you get doubly-encoded URL paths. Kotlin's encoding seems nicer. A nice benefit here is that the file paths match the URL paths. However, it works for them because square bracket chars aren't allowed as identifier names. In Pkl, the only character not allowed in an identifier is the backtick literal.
|
Maybe we can copy Dokka. We can simply represent verbatim I don't think we need a special way to represent
One downside is that we now use four bytes to represent one byte, which might be a problem with URL addresses. But this is an edge case that maybe we can live with. Also, this is still better than percent-encoding, which uses five bytes for URL paths. Another thought: I think this new encoding necessitates |
Proposal here: apple/pkl-evolution#3 |
This works now per #489. Might need |
This is the first step in #20 and critical to unlock outside contributions.
The text was updated successfully, but these errors were encountered: