[SR-1195] Dependency names that differ only in case cause conflicts #5460
Comments
|
Another option is to lint Package.swift and generate warnings. If the GitHub URL used is not standard we can output a warning. |
|
Comment by Logan W Wright (JIRA) There's two types of warnings. One is before push which could be useful, but it's tougher to enforce linting since there's no centralized submission that would require a lint to pass, similar to cocoapods. The second is to warn on use when the user calls `swift build`. The issue with this is that there's no resolution that doesn't involve lots of tedious forking and tag updates. I think a more long term solution would be finding a way to recognize equivalent dependencies somehow. Whether that's HEAD checks, or provider specific, or something we haven't thought of yet. |
|
> The second is to warn on use when the user calls `swift build`. The issue with this is that there's no resolution that doesn't involve lots of tedious forking and tag updates. This is what I would expect. There's no resolution if the package has been published, but anyone doing that without fixing their warnings first doesn't deserve to have their package used. |
|
Comment by Logan W Wright (JIRA) > anyone doing that without fixing their warnings first doesn't deserve to have their package used. That's a good point. Any thoughts on how you might lint? It seems that if spm is checking if the url is a github url during a lint, it could probably normalize the url through the same process. |
|
I'd rather not normalize the URLs as we may do it wrong. It is better to incorrectly warn and have someone submit a PR to fix the linter than disable a potential workflow. The linting could occur whenever the Package.swift is parsed. Should it happen for all packages or just the root package? Probably all I think. |
|
Comment by Logan W Wright (JIRA) I would think all, as well. It helps enforce the idea that perhaps you shouldn't use a package that isn't checking with a linter first when it shows sub dependency issues. |
|
Comment by Alex Pardoe (JIRA) I've also noticed a problem with this but when a package (in this case the same package) is being loaded from two different sources. The problem packages in my case have been: https://github.com/SwiftX/C7.git One is a dependency of a Zewo package the other is a dependency of a VeniceX package. As there isn't a centralised repository of Swift packages (à la RubyGems) would it be valuable to namespace package downloads somehow to prevent these conflicts? I feel this may even be valuable if there were a centralised repository of packages because, for example, I may have my own slightly modified version of an open source package that I depend on (e.g. a fix for an unmaintained package) but I wouldn't want it to conflict with the version a third-party package requires. |
|
Related to SR-1168 |
|
There are a couple of things here:
We need to come up with a proposal for an approach that deals with each of these. |
|
Comment by Nicolas Zinovieff (JIRA) Don't know how relevant this conversation still is, but since it was linked from a new issue we raised with the Kitura folks, I wondered how "unique" commit checksums were and if they could be used to identify a specific package across several repos / forks. Two things with different URLs but same commit SHA would therefore be "the same" and not to be duplicated Of course, this doesn't help with versions, as one dependency could rely on 1.7.2 and the other on 1.7.1. I guess that for that purpose, there would still be a need for a canonical name, which would help detect version conflicts as well as name conflicts ( reference: https://bugs.swift.org/browse/SR-3975 ) |
|
This shouldn't be a problem anymore due to package identity. We still need to detect forks which is tracked by https://bugs.swift.org/browse/SR-1168 |
Additional Detail from JIRA
md5: 305e77ce844e35ef1fd2d5269878595a
is duplicated by:
relates to:
Issue Description:
If two dependencies are declared that use different casings in the spelling, for example.
.Package(url: "https://github.com/swiftx/s4.git", majorVersion: 0, minor: 2)And somewhere else in the dependency tree:
.Package(url: "https://github.com/SwiftX/S4.git", majorVersion: 0, minor: 2)Then there will be a collision
By normalizing all urls to lowercase and requiring .git suffix, we can ensure that these types of collisions do not occur. Please let me know if you have any feedback on things I should adjust or if you'd prefer an alternative approach to the solution.
Unfortunately, different providers have different casing rules so the issue is more complex.
For example:
Github.com - No casing
BitBucket.org - Project name is case sensitive, no other part is.
Possible solutions:
1. Special Cases for Providers, ie: if contains github.com { ... if contains bitbucket.org { ...
This is probably the easiest in short term, but limits new providers. Self hosted repositories are likely not public, and could enforce accurate casing.
2. HEAD request to normalize url
There are issues w/ this if running a github url w/o `.git` suffix where the data returned doesn't seem to include a normalized url. (at least that's what I gathered from my curl request)
3. ??
My feeling is that 1 is the best solution in the interim. The issue is not easy to solve in large dependency trees and there's no harm to providing a specialized case for Github.com. Considering it powers the majority of packages I think it is warranted. Those not powered by Github.com will continue to function as they do currently, so the cost isn't that great. I'd love to discuss the possibility of a more robust long term solution if this is not agreed to be the best course of action.
@ddunbar
@mxcl
The text was updated successfully, but these errors were encountered: