-
Notifications
You must be signed in to change notification settings - Fork 40
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
Comments
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). |
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? |
@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:
|
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 An example is the "configuration" gem. I have such a gem too. I like the name "configuration". Ideally we could one day have means to install "attached" or "owner-specific" gems, similar It's not so trivial, though. I think it needs a much larger discussion involving lots of people
Well, this may be an additional benefit to offer more protection. But always remember that (It would also be good to get matz to this eventually, because "gem" taps into |
I think it makes sense to transfer this issue to https://github.com/rubygems/rfcs until there's an RFC that can be implemented? |
@deivid-rodriguez yup, let's do that. |
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. |
@indirect What was the reason for closing? Is it just because a formal RFC wasn't created yet? |
This is a discussion ticket, and the discussion ended in March. What would the reason be for leaving this ticket open? |
Proposal is here: #40 |
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 asgem install aws::s3
orgem install rails/actionwhatever
The text was updated successfully, but these errors were encountered: