-
Notifications
You must be signed in to change notification settings - Fork 6
Fork Support
We’re in the process of trying to figure out how to deal with forked or ‘namespaced’ gems. Add your own ideas in, or hop in #gemcutter on Freenode if you’re feeling for some more instantaneous feedback.
Some more links/research on this:
Gem Name: The current way with GitHub Gems. Basically, tack on the ‘namespace’ onto the gem name but leave everything else as is.
Namespace: Modify the gemspec to contain a ‘namespace’ field.
Source: Allow users to register a subdomain of gemcutter.org and push forked install gems to that. The root domain remains the trusted/real repository.
Version: Shove the ‘namespace’ into Gem::Version, so something like gem 'jekyll', 'qrush-1.0.0'
Evaluating some pros/cons of each solution.
| Options | Gem Name | Namespace | Source | Version |
|---|---|---|---|---|
| Pros | ||||
| Doesn’t change workflow for the primary use case | X | X | X | X |
| Ability for gems to specify forks as dependencies | X | X | X | X |
| Cons | ||||
| Requires modifying Rubygems | X | X | X | |
| Cumbersome installation of forks | X | |||
| No polymorphism of gems (i) | X | |||
(i) If another gem or a Rails app explicitly requires qrush-gemcutter, then only that gem satisfies the dependency rather than any ‘gemcutter’ fork that supports the same API.
Feel free to add your thoughts below this. -@qrush
Another potential issue which is really worth consideration, is that of encouraging or discouraging gem forks in the first place. Ruby itself lacks name spacing support, as such using fork gems in these ways can lead to the inability to load other gems that subsequently depend on non-fork versions, or other fork versions. Another really much better option, is to release a new gem, with code in a new namespace, if the code is not going to get pulled back into the original code base. Opening up repositories to reputable contributors (following clear rules, like writing tests / keeping patches clean) should also be encouraged to aid in faster release cycles where appropriate. Faster release cycles also require a keener understanding of versioning semantics. -@raggi
raggi: I’m all for this, but I feel that GitHub has given the Ruby community a new model of development that can’t easily be backed out of. The ability to “fork” a gem and publish it seems like a feature that has worked well since gems.github.com started, and if they start preferring to point users towards gemcutter instead we’ll need to address this issue somehow. -@qrush
qrush: Alas, I’ve been against that for the start due to this issue, @tmm1 can attest to this, being that I went off on a massive rant about it at him a long time ago. Moving forward I think we need to make it easier for people to do the right thing, rather than maintain ease for the wrong thing – but of course, that’s what this discussion is about. My point is, I think there’s two aspects under discussion, first of all what is the right way? and second how do we help people do it the right way more easily? -@raggi
I’ve added “no polymorphism between forks with the same API” to the cons list. – @drnic
The above version proposal above won’t be accepted into RubyGems. However, alpha portions can be appended to versions and mark the gems as “prerelease” right now. (gem “rake”, “0.8.7.drbrain”) – @drbrain
My rubygems+github proposal can be considered similar to the namespace proposal in that the “namespace” is contained in the signing keys. – @drbrain