Why does SPM use GitHub repo name and not Package.swift name?

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.

  1. 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?

  2. 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,

            name: "example",
                .product(name: "JSON", package: "ss-json"),

but the actual name of the package in the Package.swift is swift-json, and this is what people expect to write in the package: field.

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.

1 Like

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.

1 Like

i just ended up moving the ss-json repository to swift-json, better to get it over with early…