running into this issue while testing
ss-json, which is named
swift-json in the
Package.swift in order to follow pure-swift library naming conventions.
the SPM seems to ignore the
Package.swift name and uses the GitHub repo name instead, which strikes me as odd. the workaround, which is to use
package(name:url:from:), is deprecated:
Package.swift:11:10: warning: 'package(name:url:from:)' is deprecated:
use package(url:from:) instead
.package(name: "swift-json", url: "https://github.com/kelvin13/ss-json", from: "0.1.0"),
The convention was originally intended to identify a package as belonging to Swift, not written in Swift. (But it was never communicated very well and has been widely co‐opted.)
It has been dancing in circles for the last few versions of Swift, due to an initially erroneous implementation and then side‐effects of the work on the new package identity definition. I am now so confused I can no longer remember either what it does in which release or what it is supposed to do.
Do you mean that there is a definitive bug? Such as:
- it being impossible to write your manifest without warnings
- it being impossible to write a single manifest that works across the various platforms and IDEs
Or do you just not like what said warning‐free manifest looks like?
How would be your preferred way of expressing your manifest (even if it does not work today)?
the problem is that when using the package, you have to write,
.product(name: "JSON", package: "ss-json"),
but the actual name of the package in the
swift-json, and this is what people expect to write in the
the url of the repository is a hosting detail, and should not affect the strings passed to
product(name:package:). while moving the GitHub repository is theoretically possible, it would break all incoming links and confuse users.
Your expectation matches the original iteration of SE‐0226 as written. (When it was implemented in Swift 5.2, the target dependency erroneously used the last path component instead, which was fixed in some later version.)
Around the time of SE‐0292, SE‐0226 was amended to eliminate the
name attribute, and now you are supposed to specify the identity, which for a URL dependency is the last path component. I do not remember at what version that change was actually made, but it think the implementation does properly distinguish each side of the tools version.
Speaking for myself, I am on the fence about which is better. On the one hand, I prefer the full freedom of the text string over the restrictions of the identifier, but on the other hand, the simplification does result in less parameters. So I ended up not really participating in that review. But with hindsight I can say that the whiplash has been as confusing as it was annoying. And so I cannot imagine myself supporting a proposal to flip it yet again.
so, what does all this mean for
ss-json? for that matter, what happens if a an established library is discovered to have a naming conflict with another library? politically this would already be a complicated situation even if renaming one of the libraries by changing the
Package.swift was an option, now even that potential resolution is off the table.
i’ve heard package names being described as a “global namespace”. if that’s the case, doesn’t it make it more important than ever that there are ways to defuse potential conflicts that don’t involve forcing one of the packages to migrate to a completely new repository?
If I remember correctly, this was sort of a phase one to break the connection to what is actually in the dependency manifest. The intended eventual phase two was to enable you to christen it whatever you want at the package dependency declaration. The purpose was to solve precisely what you describe. It just has not been particularly pressing, because the module name clashes also needed a solution in order for it to actually be useful. That review just concluded.
i just ended up moving the ss-json repository to
swift-json, better to get it over with early…
Does that all means that package name must be the same as git repository name? (last path component). This is a bit unfortunate. Does it means I can't host more than 1 package in one repo?
The package name does not have to be the same as git repository name. At this point the
name argument passed to
Package initializer is used only for display purposes.
You can host as many packages in a single repository as you want, but if you're adding that repository as a dependency to some other packages, IIUC you can't directly specify a specific package you depend on in that repository. In that case you'd have to create a "root" package and expose other packages as "subpackages".
Currently this would not be supported for SCM based dependencies, they can only contain a single package at the root.