Fork Support

We’re in the process of trying to figure out how to deal with forked or ‘namespaced’ gems.

Some more links/research on this:

• mojombo’s proposal for namespaces
• drbrain’s rubyforge + github proposal

Options

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'

The Lineup

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
Ability for gems to specify forks as dependencies	X	X	X	X
Cons
Requires modifying Rubygems		X	X	X
Cumbersome installation of forks			X

Opinions

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