Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use "gem" instead of "rubygems" to match purl spec #114

Merged
merged 2 commits into from
Dec 8, 2023

Conversation

juspence
Copy link
Contributor

@pombredanne I see you've authored most of the recent commits. Sorry for the noise if you're not the right person to tag here.

My team has always generated purls for Ruby Gem packages that start with "pkg:gem/". This matches the official spec, which mentions "pkg:gem/" four times:
https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst

The spec doesn't ever mention "pkg:rubygems/", but purl2url generates purls like this, and does not accept any purl like "pkg:gem/". To fix this, I make two small changes:

  1. When generating a URL from a purl, accept purls like "pkg:gem/" in addition to "pkg:rubygems/". I don't know if multiple decorators will work, but if so then this change is backwards-compatible.
  2. When generating a PURL from a URL, generate purls like "pkg:gem/" instead of "pkg:rubygems/". This change is not backwards-compatible.

My opinion is that having two very similar purl types for the same package type is unnecessarily confusing to the users. I chose to standardize on "pkg:gem/" here when generating the purl since that's the example given in the spec. If "pkg:rubygems/" is the more correct option, I can open a PR to update the examples in the spec.

If multiple decorators won't work, or if you'd prefer to avoid backwards-incompatible changes, I could add a separate router that treats "pkg:gem/" as a completely new purl type. Then the existing code for "pkg:rubygems/" wouldn't need to change.

In general, I'm happy to make any changes you recommend. Thanks for your review.

@pombredanne
Copy link
Member

@juspence Thanks! great catch! this is a bug indeed.

@juspence
Copy link
Contributor Author

juspence commented Feb 15, 2023

I tried to fix only the linting errors in the files I touched, but after looking at the diff I guess these were existing errors? There are also changes to other files which I haven't committed. I'm just going to put things back the way I originally found them, and remove the "pkg:rubygems/" decorator based on your feedback above.

@pombredanne
Copy link
Member

Do not worry about Travis... I need to disable this.

@ronkorving
Copy link

Sorry for the noise, but I would love to see this land :)

@tdruez tdruez merged commit bdbc8c8 into package-url:main Dec 8, 2023
16 checks passed
tdruez added a commit that referenced this pull request Dec 8, 2023
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Dec 11, 2023
0.12.0 (2023-12-08)
-------------------

- Modified `PackageURL.from_string` to properly handle golang purls.
  package-url/packageurl-python#115

- Improve support for PyPI URLs in `url2purl`.
  package-url/packageurl-python#128

- Return the "gem" type instead of "rubygems" for "https://rubygems.org/" URLs in
  `url2purl`. The `pkg:rubygems/` purls are backward-compatible in `purl2url`.
  package-url/packageurl-python#114

0.11.3 (2023-12-08)
--------------------

- Add support for GitLab "/archive/" URLs in `url2purl`.
  package-url/packageurl-python#133
tdruez added a commit that referenced this pull request Feb 12, 2024
Signed-off-by: tdruez <tdruez@nexb.com>
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Mar 3, 2024
0.14.0 (2024-02-29)
-------------------

- Add support for getting golang purl from go import.
  aboutcode-org/purldb#259

- Fix the "gem" type in the README docs.
  package-url/packageurl-python#114
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants