Bugs item #27109, was opened at 2009-09-16 01:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126
Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: James Tucker (raggi) Date: 2009-09-17 08:03 Message: Adam - what you don't seem to understand is that sources are completely separate from gems. My gems are available from gemcutter, rubyforge and github, for example. You could do: gem install subload --source http://gems.rubyforge.org/ gem install subload --source http://gems.gemcutter.org gem install raggi-subload --source http://gems.github.com Any of which will work. Rubygems can store these, and my .gemrc looks like this: :sources: - http://gems.rubyforge.org/ - http://gemcutter.org - http://gems.github.com So when I type gem install <some_gem> it will try rubyforge first, then gemcutter.org, then gems.github.com. Dependencies could be on any or *all* of the three sources, I see no reason to to put restriction on this flexibility. All that would lead to is a "weakest link" problem, and over time as gem servers are deprecated or come into disservice those gems that have dependencies forcefully relying on them will be broken due to this feature you request. The resolution at this point would be to fetch the gem, unpack it, strip any signatures, open the gemspec, remove the dependency source, then repack the gem. Why would we ever want to do this? As for gemcutter, it's not finished, and still has issues, for example rspec is currently publishing prerelease gems to it, but they are not marked as prerelease by gemcutter, because the product is unfinished. Fact of life, new things take time to be completed. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 05:39 Message: OK guys. I'll leave it in your capable hands. If, a) no two differing gems can have the same name (I actually really like github's solution to this) and b) other gem sources are at least able to compete as 'legitimate' external gem sources (by which adding a source to the .gemrc seems as good a solution as any) I guess I can't really complain. I probably won't publish my gem to rubyforge as everything will work for me as setup on gemcutter. The users have to install gemcutter to install my gem anyway. I just raised this issue here because it seemed like a solution to a problem I was trying to forsee (and that I haven't actually encountered yet, admittedly). Cheers, ---------------------------------------------------------------------- Comment By: John Barnette (jbarnette) Date: 2009-09-17 04:40 Message: Specifying dependency sources would also break a significant number of companies who run combined internal gem servers. AT&T, for example, runs an internal gem server which mirrors *all* GitHub and Rubyforge gems, and all deploys use the internal mirror. If gems could specify dependency sources, mirrors like this would have to find a way to override those sources. Cross-source dependency resolution is definitely something we need to smooth out, but explicit dependency sources isn't the way to do it. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 03:50 Message: OK. Just to clarify. I do understand that it will complicate things, but I still think the large gem publishers will always find ways to make life easier for their users. i.e. publish to rubyforge... but no... I can't say I agree that no gem should ever have a specific source dependency. Small gem publishers might come and go, but gems already break because of version changes... it's the same thing (in my mind). The larger projects will probably never use source dependencies, but source dependency helps encourage change and competition for smaller gems (again in my mind). As the gem grows they will have to work out any issues.... Hopefully haven't offended anybody. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 03:36 Message: I understand the want to have gems work by default, but really think this is overcomplicating a simple issue. People are and will continue to want to publish gems to various gem providers. It's the way people are. This all started because I asked for somebody to publish a gem as a dependency and that gem got published to gemcutter. I was essentially forced to publish my gem to gemcutter so that I could use that dependency. I like the idea that other gem sources should be allowed to flourish. The (best) major ones will always win out... I don't see this gem apocalypse you envision. It is _not_ a bug (in my mind) that somebody didn't release their gem to rubyforge. No matter how easy or friendly it is. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 10:47 Message: Ryan - lol, sorry :-( It's useful, as a minimal starting point, for me. My main gripe of hoe is the task names, which i know is totally minor, but anyway, that's another discussion for somewhere else... ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-16 09:38 Message: Don't fool yourself. That isn't even close to what Hoe is capable of. :P ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 09:20 Message: Here is a rakefile that's largely as capable as hoe.rb, but self contained, and a single file. This would help with releasing to rubyforge, and also supports maintaining a .gemspec for github, making releasing on both systems trivial. http://github.com/raggi/subload/blob/master/Rakefile ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 09:17 Message: Several things here: 1. Rubyforge is the authorative source for rubygems. 2. Gemcutter although functional is not finished, and the discussion of merging it with the rubyforge source is underway - but only when it's ready. 3. Gemcutter requires gems be authorised for name clobber 4. Github won't publish gems that have the same name as a rubyforge gem 5. Gem security policies could be used to solve the auth problem 6. Contrary to popular (uneducated) belief, it is remarkably easy to publish gems to rubyforge using the rubyforge gem. 7. Despite it's php roots, rubyforge is very useful. 8. Gem files are not tied to a source, and never should be, that's centralisation and coupling that will be utterly destructive in future. 9. Github gem hosting is likely to leave soon, according to chris. 10. If you find a gem that isn't on rubyforge, then I recommend you submit that as a bug report. In my opinion that's *very* bad release policy. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 09:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 08:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
