Show library names instead of package identifiers
Is your feature request related to a problem? Please describe.
Some packages have different identifiers and names. Do we show library name same as Xcode?
The package I'm using is Realm
.package(url: "https://github.com/realm/realm-swift", .upToNextMajor(from: "10.28.0")),
Do you prefer to show library names instead of package identifiers?

Describe the solution you'd like A clear and concise description of what you want to happen.
Showing the list same as Xcode
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
the right view is from Xcode, the left one is VSCode, I know there is not much difference but engineers could switch between VScode and Xcode smoothly
Additional context Add any other context or screenshots about the feature request here.
Is this easy to implement?
It feels like the VS Code pattern (current) is more precise🤔
SwiftPM is resolving packages using their identifier instead of package name now. This means there could be packages with the same name but different identifier.
Is this easy to implement?
I think it is — given that both identifiers and names are cached in workspace-state.json.
It feels like the VS Code pattern (current) is more precise🤔
either is OK to me.
the difference is what we want to "focus" on more, the libraries we are using? the packages we are using?
Is this easy to implement?
Yes, It's easy
It feels like the VS Code pattern (current) is more precise🤔
SwiftPM is resolving packages using their identifier instead of package name now. This means there could be packages with the same name but different identifier.
I thought the names had to be unique. For example, when you reference a product in a target dependency you use the package name. If they weren't unique that would be problematic.
Is this easy to implement?
I think it is — given that both identifiers and names are cached in
workspace-state.json.
I thought so
For example, when you reference a product in a target dependency you use the package name. If they weren't unique that would be problematic.
I believe identifier is used instead. Package name were used if I remembered correctly.
From my perspective, what we’re actually using is package (by identifier) - product (by name) - target (by name), so maybe a better solution is to restructure the tree view and add a “Products” field. Check out GitLens for utilizing the list view?
the PackageIdentity is exactly the lastComponent of URL
https://github.com/apple/swift-package-manager/blob/main/Sources/PackageModel/PackageIdentity.swift#L276
Usually, it's the same with the packageName but it could be different.
@stevapple When you add a package as a target dependency you use the package name. So these need to be unique.
dependencies: [.product(name: "RealmCore", package: "RealmDatabase")],
@adam-fowler I believe package: should take package identifier instead of its "name" here. The name: field in Package.swift is not intended to be used any more. It’s clearly marked as displayName internally and thus should be used for display only (but duplication is a real problem).
Excuse me for pulling you in here @tomerd, but wdyt?
@stevapple well that isn't what the swift-realm is doing https://github.com/realm/realm-swift/blob/master/Package.swift
@stevapple well that isn't what the swift-realm is doing https://github.com/realm/realm-swift/blob/master/Package.swift
It is using a deprecated API with
dependencies: [
.package(name: "RealmDatabase", url: "https://github.com/realm/realm-core", .exact(Version(coreVersionStr)!))
],
which explicitly sets the identifier to RealmDatabase.
APIs with custom package name: are deprecated in SwiftPM 5.6.
@stevapple RealmDatabase is the package name the url last component is the identifier if im correct, the name could mean more to me (my question was a bit wrong)
@stevapple RealmDatabase is the package name the url last component is the identifier if im correct, the name could mean more to me (my question was a bit wrong)
Yeah I know we’re a bit off-topic😅
You're right that the package name is intended to be displayed, but I’m a bit worried about duplications. They could happen, you can easily reproduce one with local dependencies.
And SwiftPM is somehow regarding the name as legacy, see apple/swift-package-manager#3851
Just tested it with a remote package and a local package.
Case 1
.package(path: "line-sdk-ios-swift"),
.package(url: "https://github.com/line/line-sdk-ios-swift.git", .upToNextMajor(from: "5.8.2"))
if the name(last path component) is same. error will throw out in the beginning
$ swift package show-dependencies --format json
'spm5.5': error: duplicate dependency 'line-sdk-ios-swift'
Case 2
.package(path: "line-sdk-ios-swift1"), <-- HERE makes the identifier different
.package(url: "https://github.com/line/line-sdk-ios-swift.git", .upToNextMajor(from: "5.8.2"))
$ swift package show-dependencies --format json
error: multiple products named 'LineSDK' in: 'line-sdk-ios-swift', 'line-sdk-ios-swift1'
error: multiple products named 'LineSDKObjC' in: 'line-sdk-ios-swift', 'line-sdk-ios-swift1'
error: multiple targets named 'LineSDK' in: 'line-sdk-ios-swift', 'line-sdk-ios-swift1'
error: multiple targets named 'LineSDKObjC' in: 'line-sdk-ios-swift', 'line-sdk-ios-swift1'
it seems the identifier/product name/target should be unique somehow that are handled by SwiftPM and engineers
it seems the identifier/product name/target should be unique somehow that are handled by SwiftPM and engineers
As you can see, manifest name does nothing here. SwiftPM only cares about the identifier.
Notice that name: parameter in .package(name:url:) is confusing (it is actually specifying the identifier), so it is deprecated now, and likely to be removed in Swift 6.
SwiftPM only cares about the identifier
it makes me worried about the identifier that Apple uses the repo name as the identifier
because its much easier to have a same identifier by forking rather than a package name
in the practice of CocoaPods, there seems to be no problem in the tool level
If you forked a package and thus having the same identity, aren’t these two libraries basically one and the user should choose either of them?
in the practice of CocoaPods, there seems to be no problem in the tool level
SwiftPM can have no problem either — with registry support. Path and URL based packages don’t have namespaces, so they can easily collide. This is one of the reasons to push registry work.
Decided to stick with identifiers