search

spdx / tools

SPDX Tools
Apache License 2.0
126 stars 69 forks source link

Methods to work with VCS location URLs #194

Closed grv87 closed 4 years ago

grv87 commented 5 years ago

Are there plans to add methods to create/parse/validate VCS location URLs, specified by § 3.7 of Specification? I mean, URLs like

git+https://git.myproject.org/MyProject@da39a3ee5e6b4b0d3255bfef95601890afd80709#lib/variable.rb
goneall commented 5 years ago

Not currently, but not a bad idea. I would invite a pull request, but there is some significant refactoring going on to support the 2.2 release. We can leave this open to track and implement once the code settles down.

silverhook commented 5 years ago

Forgive me, if I misunderstand this issue, but AFAICR there was some talk that SPDX would implement Package URL, which if I see this correctly, would solve this.

grv87 commented 5 years ago

@silverhook, that would be the best solution. But it means new version of specification. And how to handle everything already written in current version? At least, there should be converter from current URLs to purl.

silverhook commented 5 years ago

Pulling in @pombredanne, if he has more to say on this topic.

pombredanne commented 5 years ago

Package URLs and VCS URLs are two different and complementary things, at least that the way I always envisioned these two since I am a tad behind both. A Package URL implies that there is some type, name and version and some public repository of sorts. A VCS URL can exist irrespective of any of these. There are cases where the two may look furiously the same though: many Composer or Go packages are coming straight from a Git repo. The github Package URL may also look like a VCS URL... BUT these are different and complementary things. For instance, a bitbucket Package URL says nothing by default about which version control is used (it could be Git of Mercurial)

grv87 commented 5 years ago

Package URLs and VCS URLs are two different and complementary things

SPDX uses VCS URLs only as an option for Package Download Location.

Package URL says nothing by default about which version control is used (it could be Git of Mercurial)

If specific package type is installable from VCS then Package URLs already cover (or should cover) such URLs. Examples from purl readme:

I agree that pointing to VCS as where sources are located is a different case. It isn't covered by both SPDX and PURL now (off-topic: there is, for example, special syntax supported by Maven).

On github and similar purl types I agree with https://github.com/package-url/purl-spec/issues/59. They are as useless as VCS URLs in current SPDX specification. Both say nothing about package type and so can't be resolved. Compare example above with git://github.com/gorilla/context@234fd47e07d1004f0aed9c (SPDX VCS URL) or github://gorilla/context@234fd47e07d1004f0aed9c (Package URL). So, converting from SPDX VCS URLs to Package URLs, which I wished earlier, can't be done without providing some extra info.

Overall, I don't see any problems using PURLs in SPDX. I'm even tempted to close this issue since SPDX specification actually accepts any URLs. So, PURLs are already covered. And, concluding that VCS URLs are useless there is actually a little need to support them.

Thanks everybody for discussion and insights!

goneall commented 4 years ago

@grv87 I'm OK closing this and going with PURL - as you state above, URL's are already accepted.