Expected PURL for swift #53
Comments
|
@ken-duck, I think you've interrupted the spec correctly and applied it to swift quite well. @pombredanne This is my thoughts on swift: swift for Swift packages There is no default package repository: the namespace is implied from dependencies defined in Packages.swift
Examples: |
|
@stevespringett any reason why |
|
@jdillon I was really hoping this would be pointed out. I wanted to draw attention to the golang requirement that the namespace and name be lowercase since @ken-duck referenced it. In golang, the modules are lowercase, but the examples also point to external sites, like GitHub, similar to how we're doing swift. I do not think swift should be lowercased due to uncertainty of the target site being referenced in the namespace is case-sensitive or not. For example, Github is case aware, not case sensitive. So case doesn't matter much, but if another provider was referenced, then that provider may be case sensitive. swift for Swift packages There is no default package repository: the namespace is implied from dependencies defined in Packages.swift
Examples: We may want to consider removing this requirement from golang as well. |
|
In terms of DNS names, like github.com only that portion could potentially be considered insensitive, everything else totally depends on the server implementation. Github for example treats these the same: But another service may not. I think this again falls into the section of leave it as given; as the more per-type transformations to normalize imply more chances that any given time any "spec compliant impl" may be wrong if some new format gets introduced with new transformation rules. Related to: #38 I also suggest that if some format has some requirement saying name or namespace is lowercase or uppercase or whatever, that the purl spec shouldn't care about that either; and a user configures a purl for one of those types with invalid case, then the purl just is invalid in terms of that specific ecosytem, but in terms of the general purl specification is valid. IMO there should be zero type-specific transformations. Only generic applicable to all normalizations. And I think wrt to case, the only field that can be mutated like this is the type. Everything else is going to be very ecosystem specific and IMO its not possible or reasonable to implement a proper spec compliant implementation that could ever be spec-valid with these sorts of transformations. |
|
Thanks for the feedback @stevespringett ! |
|
My question was answered satisfactorily, and it looks like discussion has ended. Thanks for the help! |
Previously, tuples of the form `(VCS host organization name, package name)` have been used. However, such tuples are not guaranteed to be unique, because the name of the VCS host is not included. Looking at how dependencies are defined for SPM packages [1], it becomes clear that the repository URL is actually used as the key / identifier, not the package name (plus maybe with the organization name). Note that [1] says that "Each dependency specifies a source URL and version requirements. The source URL is a URL accessible to the current user that resolves to a Git repository." Furthermore, SPM allows only one package to be present per repository, which in fact makes the repository URL a good candidate to be used as ID. Note that the restriction to one package per repository used to be too restrictive in some cases which is one reason why the concept of so called targets [1] has been introduced. However, ORT's `Spm` integration currently does works on package granularity only and does not look at the more fine grained targets. The approach to specifying dependencies by their repository is very similar to the approach Go modules has taken. So, using an analog format for the IDs of packages seems to be a better fit, which also ensures the uniqueness of the IDs. Note also the discussion in [2]. [1] https://www.swift.org/package-manager/ [2] package-url/purl-spec#53 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
Previously, tuples of the form `(VCS host organization name, package name)` have been used. However, such tuples are not guaranteed to be unique, because the name of the VCS host is not included. Looking at how dependencies are defined for SPM packages [1], it becomes clear that the repository URL is actually used as the key / identifier, not the package name (plus maybe with the organization name). Note that [1] says that "Each dependency specifies a source URL and version requirements. The source URL is a URL accessible to the current user that resolves to a Git repository." Furthermore, SPM allows only one package to be present per repository, which in fact makes the repository URL a good candidate to be used as ID. Note that the restriction to one package per repository used to be too restrictive in some cases which is one reason why the concept of so called targets [1] has been introduced. However, ORT's `Spm` integration currently works on package granularity only and does not look at the more fine grained targets. The approach to specifying dependencies by their repository is very similar to the approach Go modules has taken. So, using an analog format for the IDs of packages seems to be a better fit, which also ensures the uniqueness of the IDs. Note also the discussion in [2]. [1] https://www.swift.org/package-manager/ [2] package-url/purl-spec#53 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
Previously, tuples of the form `(VCS host organization name, package name)` have been used. However, such tuples are not guaranteed to be unique, because the name of the VCS host is not included. Looking at how dependencies are defined for SPM packages [1], it becomes clear that the repository URL is actually used as the key / identifier, not the package name (plus maybe the organization name). Note that [1] says that "Each dependency specifies a source URL and version requirements. The source URL is a URL accessible to the current user that resolves to a Git repository." Furthermore, SPM allows only one package to be present per repository, which in fact makes the repository URL a good candidate to be used as ID. Note that the restriction to one package per repository used to be too restrictive in some cases which is one reason why the concept of so called targets [1] has been introduced. However, ORT's `Spm` integration currently works on package granularity only and does not look at the more fine grained targets. The approach to specifying dependencies by their repository is very similar to the approach Go modules has taken. So, using an analog format for the IDs of packages seems to be a better fit, which also ensures the uniqueness of the IDs. Note also the discussion in [2]. [1] https://www.swift.org/package-manager/ [2] package-url/purl-spec#53 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
Previously, tuples of the form `(VCS host organization name, package name)` have been used. However, such tuples are not guaranteed to be unique, because the name of the VCS host is not included. Looking at how dependencies are defined for SPM packages [1], it becomes clear that the repository URL is actually used as the key / identifier, not the package name (plus maybe the organization name). Note that [1] says that "Each dependency specifies a source URL and version requirements. The source URL is a URL accessible to the current user that resolves to a Git repository." Furthermore, SPM allows only one package to be present per repository, which in fact makes the repository URL a good candidate to be used as ID. Note that the restriction to one package per repository used to be too restrictive in some cases which is one reason why the concept of so called targets [1] has been introduced. However, ORT's `Spm` integration currently works on package granularity only and does not look at the more fine grained targets. The approach to specifying dependencies by their repository is very similar to the approach Go modules has taken. So, using an analog format for the IDs of packages seems to be a better fit, which also ensures the uniqueness of the IDs. Note also the discussion in [2]. [1] https://www.swift.org/package-manager/ [2] package-url/purl-spec#53 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
Previously, tuples of the form `(VCS host organization name, package name)` have been used. However, such tuples are not guaranteed to be unique, because the name of the VCS host is not included. Looking at how dependencies are defined for SPM packages [1], it becomes clear that the repository URL is actually used as the key / identifier, not the package name (plus maybe the organization name). Note that [1] says that "Each dependency specifies a source URL and version requirements. The source URL is a URL accessible to the current user that resolves to a Git repository." Furthermore, SPM allows only one package to be present per repository, which in fact makes the repository URL a good candidate to be used as ID. Note that the restriction to one package per repository used to be too restrictive in some cases which is one reason why the concept of so called targets [1] has been introduced. However, ORT's `Spm` integration currently works on package granularity only and does not look at the more fine grained targets. The approach to specifying dependencies by their repository is very similar to the approach Go modules has taken. So, using an analog format for the IDs of packages seems to be a better fit, which also ensures the uniqueness of the IDs. Note also the discussion in [2]. [1] https://www.swift.org/package-manager/ [2] package-url/purl-spec#53 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
Previously, tuples of the form `(VCS host organization name, package name)` have been used. However, such tuples are not guaranteed to be unique, because the name of the VCS host is not included. Looking at how dependencies are defined for SPM packages [1], it becomes clear that the repository URL is actually used as the key / identifier, not the package name (plus maybe the organization name). Note that [1] says that "Each dependency specifies a source URL and version requirements. The source URL is a URL accessible to the current user that resolves to a Git repository." Furthermore, SPM allows only one package to be present per repository, which in fact makes the repository URL a good candidate to be used as ID. Note that the restriction to one package per repository used to be too restrictive in some cases which is one reason why the concept of so called targets [1] has been introduced. However, ORT's `Spm` integration currently works on package granularity only and does not look at the more fine grained targets. The approach to specifying dependencies by their repository is very similar to the approach Go modules has taken. So, using an analog format for the IDs of packages seems to be a better fit, which also ensures the uniqueness of the IDs. Note also the discussion in [2]. [1] https://www.swift.org/package-manager/ [2] package-url/purl-spec#53 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
I was trying to identify the expected PURL for swift packages, and was wondering if there was a suggested format.
My first guess is that it is likely similar (but not quite the same as) golang, as it appears that swift packages require both a repository path and a package name. Since a package name is required, I suspect that the repository path is all contained within the namespace.
For example, from the examples on the linked swift package site perhaps we would have:
Note that there is one description of a possible ways to allow multiple swift modules in one repository here. It is not official by any means, from what I can tell, but it appears that it could be supported using the
subpathcomponent of PURL.Does this fulfill the expectations of the PURL for swift?
Thanks
The text was updated successfully, but these errors were encountered: