GitHub

Comments and changes to this ticket

• 

  Bodaniel Jeanes August 21st, 2008 @ 11:13 PM

  +1 I think this is a pro idea. though i still believe that production gems should be kept on rubyforge for the post part.

• 

  codeofficer August 21st, 2008 @ 11:25 PM

  +1, brilliant idea :)

  ps, as a gem server I can appreciate rubyforge's history ... but all my action is at github lately. Maybe they could sex their pages up a bit, I just don't find the rubyforge site very helpful anymore, compared to what I find on github at least.

• 

  Lee Marlow August 21st, 2008 @ 11:56 PM

  What about forked projects that weren't forked via github? Search for "fork" on github. There are quite a few gems taken from other repos (git, svn, perforce, cvs, etc.) and put up on github. These projects aren't the "root" gem, but it will look like it to github.

• 

  Dr Nic August 22nd, 2008 @ 12:05 AM

  Good call. That needs an internal solution too. Aiming for one project having just its name as the gem name is a goal that may require some tweaks to github's guts. Perhaps instead of worry about "root projects" instead: * you turn on "Serve as RubyGem" * an option appears "Claim the usernameless gem name" if it hasn't been claimed already

  So now its just a flag on one repo - a fork, or one of many root projects with the same name. One of them can claim it first. Later they could give it up and let someone else use the root name. This could be a system for handling "who is the primary 'owner' of a project name globally" as well.

  Nic

  On Fri, Aug 22, 2008 at 3:57 PM, Lighthouse support@lighthouseapp.comwrote:

• 

  Tekkub August 22nd, 2008 @ 12:07 PM

  • → Assigned user changed from “” to “PJ Hyett”
  • → State changed from “new” to “open”
• 

  defunkt August 22nd, 2008 @ 06:10 PM

  It seems that this discussion is based on this complaint:

  "[username-project style gem names] makes the gem useless for being involved in dependencies of other future gems."

  How?

• 

  Dr Nic August 26th, 2008 @ 03:19 PM

  drnic-somegem - is not the gem's name; "somegem" is.

• 

  defunkt August 26th, 2008 @ 04:28 PM

  Maybe at Rubyforge, but at GitHub every project's name lives under the namespace of its owner.

  
  http://github.com/defunkt/ambition
  $ gem install defunkt-ambition
  $ git clone git://github.com/defunkt/ambition.git
  

  What I don't get is how it makes the gem useless for being involved in dependencies of other future gems.

• 

  Tekkub August 26th, 2008 @ 04:35 PM

  I believe the issue that's being brought up is this...

  User joe create a gem "stuff". Some other project creates a dependency to joe-stuff. Joe goes AWOL. Mike picks up "stuff" and pushes out a new gem. Now the dependencies need to be changed to mike-stuff in any project that wants to use it.

  Moving the user out of the gem's name would make it so that any user's version of the gem could be used without modifications to the projects depending on it, the user would simply need to know the proper source to get the specific user's gem they are after.

• 

  Dr Nic August 26th, 2008 @ 04:43 PM

  I'm suggesting there is a difference in meaning between a "project name" and "gem name".

  If the dependency of rubigen + others, say within newgem's hoe spec:

  @@@ruby p.extra_deps = [

  ['RedCloth','=3.0.3'],
  ['syntax','>=1.0.0'],
  ['activesupport','>=2.0.2'],
  ['rubigen','>=1.3.0']
  

  ]

  
  
  Then its going to look in rubygem sources for a rubygem called 'rubigen' or 'activesupport'.
  
  If you were to "gem install rails --source=http://gems.github.com" then the rails project would have to rewrite its gem dependencies from:
  
  @@@ruby
    s.add_dependency('rake', '>= 0.8.1')
    s.add_dependency('activesupport',    '= 2.1.0' + PKG_BUILD)
    s.add_dependency('activerecord',     '= 2.1.0' + PKG_BUILD)
    s.add_dependency('actionpack',       '= 2.1.0' + PKG_BUILD)
    s.add_dependency('actionmailer',     '= 2.1.0' + PKG_BUILD)
    s.add_dependency('activeresource',   '= 2.1.0' + PKG_BUILD)
  

  to

  @@@ruby s.add_dependency('jimweirich-rake', '>= 0.8.1') s.add_dependency('rails-activesupport', '= 2.1.0' + PKG_BUILD) s.add_dependency('rails-activerecord', '= 2.1.0' + PKG_BUILD) s.add_dependency('rails-actionpack', '= 2.1.0' + PKG_BUILD) s.add_dependency('rails-actionmailer', '= 2.1.0' + PKG_BUILD) s.add_dependency('rails-activeresource', '= 2.1.0' + PKG_BUILD)

  
  
  So it seems github is forcing ppl to pollute their gemspecs with github specific project information, rather than the actual gem name.
  
  I thought my original suggestion, post-rant, of allowing one fork, within a project, to be the "primary fork" was a useful one. For rubygems, the primary fork could have its gem installed by the gemname, not the full github-specific project-based gemname.
  
  The notion of a primary fork - not just the root fork - would also assist with the original root fork owner "handing over" a project to someone else, thereby helping all forkers to know where to redirect pull requests etc.
  
  If github solved this problem, then I could spend less time emailing/tweeting gem owners helping them upload their gems to rubyforge. (Which led to the original rant).
  
  If github's official rubygems policy is forever "there is no primary rubygem, just forks" then I'll stop asking for such a feature. I have a feeling that although git is distributed, many people wish to just use its distributed technology as a tool to manage and enrich their otherwise centrally organised projects.
  

• 

  Dr Nic August 26th, 2008 @ 04:43 PM

  Sorry, didn't know I needed a space between @@@ and the language in Lighthouse markup.

• 

  Dr Nic August 26th, 2008 @ 04:45 PM

  +1 to Tekkub's summary too

• 

  Tekkub August 26th, 2008 @ 04:47 PM

  LH really needs a comment preview, I bugger up syntax nearly every single time I post.

• 

  Daniel Parker October 8th, 2008 @ 08:21 PM

  +10 on this. :)

  It's not logical to force users to publish their gem also on a "real" gem server (rubyforge) if you're running a gem server here. I was actually going to post a request to suggest the exact same solution that Dr Nic proposed, and found this ticket already here.

  Since it hasn't been mentioned yet, I should mention it: Usernameless gem names will make gem forgery ever more vulnerable. There really must be a way to check the ownership of a gem if it already exists at rubyforge. If a gem already exists on rubyforge, github doesn't want to grant overruling ownership of that gem to any random user. Perhaps a code can be generated that can be placed on rubyforge to prove ownership. But the other direction is important also. If someone makes a gem on github, you don't want someone else going to rubyforge and posting the same gem with a higher version.

  Github, you might have to work with Rubyforge on this one.

  One solution there would be to just start intelligently syncing your gem server with rubyforge's -- then people wouldn't have to add github as a source ... and you'd have the ownership issue all taken care of (except for the people who have an account on both sites for the same gem - which is probably because of this problem). Github and Rubyforge both can allow people to claim a root gemname if it's not already taken, and the other will know about it.