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

Discussion: Namespaced Gems? #31

Closed
mullermp opened this issue Jan 7, 2021 · 10 comments
Closed

Discussion: Namespaced Gems? #31

mullermp opened this issue Jan 7, 2021 · 10 comments

Comments

@mullermp
Copy link

mullermp commented Jan 7, 2021

I wanted to open a discussion about supporting gem namespaces. Between this repo and the RubyGems.org repo, I wasn't sure where to start this discussion. If this was opened in the wrong place, I apologize, and feel free to close it.

Regarding the issue, though: currently, anyone can go and claim any gem they want, and it is difficult for organizations with a large number of gems (such as rails, aws, etc) to reserve rights to naming. It's not only confusing to customers, but can also be a concern for security if a malicious actor claims a similarly named gem and labels it as official. Other package managers (such as NPM's scopes) have support for namespaces.

My thoughts would be to use a / or :: for namespacing, such as gem install aws::s3 or gem install rails/actionwhatever

@simi
Copy link
Member

simi commented Jan 7, 2021

Great to bring this in here, I was thinking about this for really long time. The best place would be to prepare rfc in https://github.com/rubygems/rfcs. Feel free to kick of, I'll join you with my ideas (and usecases which could be solved by this).

@mullermp
Copy link
Author

mullermp commented Jan 7, 2021

Thanks @simi for jumping in on this. I'll certainly kick start that process when I can. I don't have any formal experience writing RFC but I'll fill it in with some starter information and it can grow over time with some prototyping. I'm mainly unfamiliar with what packages will need to be touched - do you know the scope/breadth of this feature and could point to me what libraries you think would need change?

@simi
Copy link
Member

simi commented Jan 7, 2021

@mullermp just follow the readme (https://github.com/rubygems/rfcs#rubygems--bundler-rfcs). Feel free to describe it from higher level to start, I can help you pointing to the code once needed. Also feel free to skip parts not clear for now.

Good start would be to:

  1. Take a look at naming rules to prepare concept not breaking current naming (I'm not sure if / is allowed to be in gem name, but if not, it could be great candidate to use.
  2. Prepare use-cases why this is useful. I can imagine it can help typo-squating (but at the same time, it can introduce new one). Maybe namespaces could be allowed only for some kind of approved users for example. So big projects like rails, ... could use it to benefit from it.
  3. Prepare plan how to roll this feature out. Should it be open for everyone or only for some kind of approved accounts? Would be any migration needed (probably not)? ...

@rubyFeedback
Copy link

My thoughts would be to use a / or :: for namespacing, such as gem install aws::s3 or gem install rails/actionwhatever

I remember having expressed a similar idea years ago.

I am not sure it should be called "namespace"; perhaps ownership or something would be better.

But let's ignore the name for the moment.

I think a reason why this would be nice to have, would be so that we can more easily
install gems even when a name is "owned" by someone else.

An example is the "configuration" gem. I have such a gem too. I like the name "configuration".
But someone else is blocking that name for me so I can not use it in my own gems.

Ideally we could one day have means to install "attached" or "owner-specific" gems, similar
to how bundler allowed github-based repos (i think).

It's not so trivial, though. I think it needs a much larger discussion involving lots of people
and also probably the ruby core team to get on board with it, at the least people such as
Hiroshi Shibata. Change takes time. This should be well prepared.

It can also be a concern for security if a malicious actor claims a similarly named gem and
labels it as official.

Well, this may be an additional benefit to offer more protection. But always remember that
mandatory security adds a threshold level for contribution to ruby too. For example, I do
not use two factor authentication. If that would become mandatory, it would retire me
instantly from rubygems.org - yet on github I could still host the same code. So then I'd
be forced to use github more actively (right now I use rubygems.org a LOT, and barely
github at all). These trade offs should be included. But, just to clarify - I am in favour
of the IDEA behind this. After all I suggested something similar years ago too. :)

(It would also be good to get matz to this eventually, because "gem" taps into
distributing ruby code; I just don't think he would want names such as "namespace",
since that would lead to problems on the ruby CODE side. Whereas the "gem
install" command is much easier to reason about and implement. Make sure to
sync-discuss this towards rubygems.org too though; they could add an experimental
view feature in the rails code, and mark all of this as MEGA BETA for many years;
and then could, at a later point, decide whether this is useful or not. I think it will
be useful, so +1 from me)

@deivid-rodriguez
Copy link
Member

I think it makes sense to transfer this issue to https://github.com/rubygems/rfcs until there's an RFC that can be implemented?

@simi
Copy link
Member

simi commented Mar 2, 2021

@deivid-rodriguez yup, let's do that.

@simi simi transferred this issue from rubygems/rubygems Mar 2, 2021
@mullermp
Copy link
Author

mullermp commented Mar 2, 2021

I'm sorry for the radio silence on this issue. I've been caught up with other work related things. This is still a useful feature with large impact that I currently don't have the bandwidth to drive. If someone wants to own this, by all means please do.

@Fryguy
Copy link

Fryguy commented Sep 27, 2021

@indirect What was the reason for closing? Is it just because a formal RFC wasn't created yet?

@indirect
Copy link
Member

This is a discussion ticket, and the discussion ended in March. What would the reason be for leaving this ticket open?

@mullermp
Copy link
Author

mullermp commented Apr 5, 2022

Proposal is here: #40

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

No branches or pull requests

6 participants