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

Development Package Manager
1

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"),
         ^
3 Likes
2

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)?

5 Likes
3

the problem is that when using the package, you have to write,

    .executableTarget(
            name: "example",
            dependencies: 
            [
                .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.

7 Likes
4

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
5

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?

6

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
7

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

8

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?

9

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".

1 Like
10

Currently this would not be supported for SCM based dependencies, they can only contain a single package at the root.

1 Like