Fix path handling for plugins on Windows #8007
Conversation
jakepetroules
requested review from
bnbarham,
MaxDesiatov,
francescomikulis,
xedin,
dschaefer2,
shawnhyam,
bripeticca,
plemarquand and
owenv
as code owners
|
@swift-ci please test |
jakepetroules
force-pushed
the
fix-plugins-url-representation
branch
from
74c84ed to
2cfa4a0
Compare
|
@swift-ci please test |
|
I'd much rather see us adopt FilePath everywhere and get away from URLs. |
|
Unfortunately, https://github.com/apple/swift-system doesn't have Windows CI and |
That would be nice, but it's not clear to me that we'd be able to make FilePath part of the PackageDescription API, since that would introduce a new dependency on SwiftSystem (and that would require an evolution proposal and deprecation period). |
jakepetroules
force-pushed
the
fix-plugins-url-representation
branch
from
2cfa4a0 to
e31e7db
Compare
|
@SwiftCI please test |
|
@swift-ci please test |
|
@swift-ci please test Windows |
Due to RFC8089 compliance changes for Foundation.URL in Swift 6, URL.path does _NOT_ behave as one might expect, producing a path with a leading slash which will be interpreted by Windows as relative. Closes #6851
jakepetroules
force-pushed
the
fix-plugins-url-representation
branch
from
e31e7db to
c21f771
Compare
|
@swift-ci please test |
| /// This should always be used whenever the file path equivalent of a URL is needed. DO NOT use ``path`` or ``path(percentEncoded:)``, as these deal in terms of the path portion of the URL representation per RFC8089, which on Windows would include a leading slash. | ||
| /// | ||
| /// - throws: ``FileURLError`` if the URL does not represent a file or its path is otherwise not representable. | ||
| public var filePath: AbsolutePath { |
There was a problem hiding this comment.
question: Since there's some specific requirements here for this computed property, should there be some tests to cover them?
Agreed. I wouldn't want FilePath in the API, the ergonomics are still a bit suspect. It's just the one that handles Windows paths the best (according to @al45tair if I remember correctly). And FWIW, PackageDescription doesn't have URL in its API. It's just Strings which isn very type safe either. At any rate, we have plans to look deeper in the Paths issue. I'm happy with this for the near term. Or maybe it's just the better answer anyway :). |
|
@swift-ci please test windows |
Yeah. |
What argparser support are you thinking about? |
|
You know? I just yearn for Python's pathlib API but in Swift. It was really sweet to work with. |
You can't have an argument of type
|
It seems that most languages have a decent universal file path support. Go has this one in its stdlib based on regular strings. https://pkg.go.dev/path/filepath |
A lot of them get it wrong in various subtle ways, often related to encodings or unusual edge cases (Windows is especially troublesome because there are multiple ways to express the exact same path even before you consider symbolic links or reparse points, plus there is the notion of a per-drive current directory, though the system APIs only expose a single current directory directly and you get to look in the environment for the rest, so you can write things like drive-relative paths.) |
Windows definitely has its own peculiarities, such as reserved filenames like aux, com1, and lpt1. At least the differences with unix filesystem semantics isn't as wildly different as something like the z/OS filesystem or the i5/OS fs, both of which have special vendor-specific Java libraries outside of the standard nio package for working with them. Still, I think that other languages have file path libs that are able to handle the majority of cases at the intersection between unix and windows that most cross-platform packages need. |
Due to RFC8089 compliance changes for Foundation.URL in Swift 6, URL.path does NOT behave as one might expect, producing a path with a leading slash which will be interpreted by Windows as relative.
Closes #6851