GemCutter & RubyForge

[meskyanichi]

Hi,

I was wondering, what happens if you have a gem called "my-super-gem"
and you release it to GemCutter,
while at the same time, a gem called "my-super-gem" is also available
on RubyForge?

When you do a "sudo gem install my-super-gem", which is it going to
install? The RubyForge or GemCutter version?

With GitHub you have <username>-<gemname> so this will obviously never
conflict, since it'll always be unique.
How is this handled between RubyForge and GemCutter?

Sorry if this is pretty obvious, was just wondering!
I also believe I read something about a team-up/merger between
RubyForge and GemCutter, so probably the same RubyGems "hosting" will
be used for both systems?

Excited!


(I find RubyForge a bit outdated and not so nice to work with, just
recently started using GemCutter and very satisfied with it's
simplicity of use. Would be nice if RubyForge and GemCutter would
operate as one and use the GemCutter Interface!)


Thanks!
Meskyanichi

[Nick Quaranto]

The precedence depends on the order of your sources (as far as I can tell.) So if there's a gem 'foo' on both GC and RF, if GC is first in your list (what gem tumble does) you'll get the GC version.

Moving forward, I hope that Gemcutter becomes 'the' canonical gem server. My proposal in full is here: http://rubyforge.org/pipermail/rubygems-developers/2009-August/004914.html

I'm moving the move to rubygems.org will help this site feel even more 'official'. I'm trying to work out the details of that proposal with the RubyForge and RubyCentral team now, so hopefully soon I'll have some news.

-Nick

[Brian Mitchell]

It will use the order the sources are listed in. So GemCutter. As far
as github's prefix not conflicting, that isn't true. There could be a
gem called my-super-gem on rubyforge and then a user named 'my' on
github could release 'super-gem'. This would be less likely but can
still happen.

Brian.

[Adam Stacoviak [HC]]

This is awesome Nick. As a "front-end" guy, Gem Cutter and also Jeweler were a breeze to work with. I'm far more confident and motivated to produce more Gems now.

I hope this works out as you have planned. 

-AS

Sent from my iPhone

(Sorry if I'm short-winded)

[John Barnette]

On Oct 2, 2009, at 3:46 PM, Brian Mitchell wrote:
> It will use the order the sources are listed in. So GemCutter. As far
> as github's prefix not conflicting, that isn't true. There could be a
> gem called my-super-gem on rubyforge and then a user named 'my' on
> github could release 'super-gem'. This would be less likely but can
> still happen.

GitHub has validations that keep this from happening.

~ j.

[Brian Mitchell]

Well, it still suffers from the same race condition outlined by the
topic author... multi-source setups are inherently vulnerable.

Brian.

[meskyanichi]

Nick,

That sounds good!
Though, for people that want to install someone's gem (that may be new
to the community) and by default have RubyForge in their "gem sources"
(which by default is at the top of the list I believe?) It'd be a
confusing situation for the user trying to install it I think. Like,
for people that don't have much experience with RubyGems. (not that it
requires much knowledge to get it working, but if you don't know how,
then you don't).

Though, if all goes well with GC/RF then I assume this won't be an
issue since all gems will be hosted on the same server?

All in all, good stuff, very nice! Can't wait!



@brian, that's actually true. good point!

On Oct 3, 12:44 am, Nick Quaranto <n...@quaran.to> wrote:
> The precedence depends on the order of your sources (as far as I can tell.)
> So if there's a gem 'foo' on both GC and RF, if GC is first in your list
> (what gem tumble does) you'll get the GC version.
>
> Moving forward, I hope that Gemcutter becomes 'the' canonical gem server. My

> proposal in full is here:http://rubyforge.org/pipermail/rubygems-developers/2009-August/004914...