search

rubygems / rfcs

RubyGems + Bundler RFCs
45 stars 40 forks source link

Discussion: Namespaced Gems? #31

Closed mullermp closed 2 years ago

mullermp commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

mullermp commented 3 years ago

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 commented 2 years ago

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

indirect commented 2 years ago

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

mullermp commented 2 years ago

Proposal is here: https://github.com/rubygems/rfcs/pull/40