Skip to content

PackagePlugin is entirely broken #6851

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

Closed
compnerd opened this issue Aug 24, 2023 · 5 comments · Fixed by #8007
Closed

PackagePlugin is entirely broken #6851

compnerd opened this issue Aug 24, 2023 · 5 comments · Fixed by #8007

Comments

@compnerd
Copy link
Member

Description

PackagePlugin.Path has an unusable ctor:

public init(_ string: String) {
    self._string = string
}

The paths in SPM are fundamentally unusable as they do not represent a real path but some fabricated reality. They drop the drive and the resulting path is unusable. This prevents the use of build tools as the input is never found and ignored by SPM. There is currently no way to reconstruct the true file system path within the context of the plugin, which prevents build plugins from being usable.

Expected behavior

Paths provided to the plugin would be real paths with drives.

Actual behavior

Paths provided to the plugin are relative to the current drive.

Steps to reproduce

No response

Swift Package Manager version/commit hash

No response

Swift & OS version (output of swift --version ; uname -a)

No response

@compnerd compnerd added the bug label Aug 24, 2023
@neonichu
Copy link
Contributor

Isn't this the same as #5817?

@compnerd
Copy link
Member Author

Yes, #5817 might help paper over the underlying issue a bit.

@neonichu
Copy link
Contributor

I guess AbsolutePath also doesn't fully work so it can only be a partial solution. At least we wouldn't have yet another bespoke path library with a very simplistic view of path computation.

@neonichu
Copy link
Contributor

IMO, the correct solution is probably to yank PackagePlugin.Path and let people use Foundation.URL. I don't think it makes sense to force package plugins to be their own little world of their own where we have to solve common concerns of Swift programs again.

@compnerd
Copy link
Member Author

Yeah, I agree, this is best resolved by use of Foundation.URL. We should ensure that the URL is constructed properly (i.e. URL(fileURLWithPath:).).

jakepetroules added a commit that referenced this issue Sep 29, 2024
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 added a commit that referenced this issue Sep 29, 2024
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 added a commit that referenced this issue Oct 1, 2024
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 added a commit that referenced this issue Oct 1, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants