• GitHub's RubyGem Server

    pjhyett Apr 25

    Update regarding require, please read below

    The next time you visit your repository’s edit screen you’ll see a new checkbox that should be pretty exciting for users hosting their RubyGem project on GitHub:

    Gem Edit

    After checking that, managing your gem is as simple as managing a gemspec in your project’s root directory (example). Anytime you push a modified gemspec to GitHub, we’ll build and publish a new gem for you.

    Feel free to give your open source friends a hard time when they don’t release a new gem version for a while, because they have no excuse now :-)

    One concept regarding our server that bears repeating is that your gem will always be prefixed with your username. Installing mojombo’s grit gem is done via the following:

    $ sudo gem install mojombo-grit
Successfully installed mojombo-grit-0.8.1

    Using said gem works a couple of ways. First the regular require:

    $ irb -rubygems
>> require 'grit'
=> true

    Update: The following also works if you have competing versions of the same gem:

    $ irb -rubygems
>> gem 'mojombo-grit'
=> true
>> require 'grit'
=> true

    The namespacing may feel awkward as first, but it really lends itself to the distributed nature of the service we provide. Forking a RubyGem project shouldn’t be any more complicated than forking any other type of project.

    Visit http://gems.github.com for all of the details. Enjoy!

    • Comments

    • meekish about 2 hours later

      Mad props.

    • nicksieger about 2 hours later

      Would be nice if the require filenames didn’t change, but the gem activation name did instead. Or is that actually how it works? Example:
      pre. gem ‘mojombo-grit’
      require ‘grit’

    • jonner about 2 hours later

      uhh, really? You’re adding programming-language-specific customizations to your hosting service? Feel free, of course, but it seems a bit strange. When can I expect support for automatically maintaining rpm or .deb package repositories?

    • pjhyett about 3 hours later

      @nicksieger we talked about allowing require ‘grit’ at length, but not being explicit about which grit you want to require would end up being more trouble than it’s worth. The question would become, “Who’s grit did I install last? mojombo’s? mine? RubyForge’s?”
      By forcing you to require ‘mojombo-grit’ you know immediately what version of the gem you’re using.
      It’s a change of thinking and will necessitate altering your code, but we’re gonna roll with it and see if it works.

    • pjhyett about 3 hours later

      @jonner Yes, that’s exactly what we did. If enough of our customers ask us to add a feature to the site, we’re happy to oblige.
      Feel free to add a feature request here: http://logicalawesome.lighthouseapp.com/projects/8570-github/tickets

    • rtomayko about 3 hours later

      How do dependencies work in this case? e.g., if a gem depends on “foo”, does it know to look for “mojombo-foo” or is there an expectation that dependencies will be coded as “mojombo-foo”?

    • mojombo about 3 hours later

      @jonner If it’s feasible we’d love to add automatic packaging features for other technologies. Since we use Ruby extensively, that’s obviously the place that we would start experimenting with this kind of feature. If you think that automatic rpm or .deb packaging is something that we could automate in a clean way, then we’re very open to ideas about how that would work. Code examples are especially helpful in this regard!
      Here at GitHub we embrace all languages and platforms. What we’re doing is trying to make common processes for developers more streamlined. Automatic rubygem generation is just the tip of an iceberg of functionality that we’re well positioned to offer.

    • pjhyett about 3 hours later

      @rtomayko the expectation is the that dependencies would now use ‘mojombo-foo’. After all, that’s the new identifier for the gem.

    • jonner about 4 hours later

      Sure, I don’t meant to sound too negative, I’m sort of playing devil’s advocate here. You’re certainly doing a very nice job of solving a problem for a particular subset of your userbase, I just think the implementation is somewhat poorly thought-out. Think of it from the perspective of a non-ruby developer who wants to use your service. I’m trying to set up a respository for my C/C++ project, and it is asking me to decide if I want to enable “RubyGem”. Why do I have to answer this question (and possibly click the help icon to figure out what the heck it’s about)? If you then add a ‘python eggs’ feature, am I going to have to answer a question about python for my C/C++ project? What about the next language- or framework-specific feature you add. You see what I’m getting at?

    • defunkt about 4 hours later

      jonner: We offer many features only a subset of our userbase wants or is able to take advantage of.

    • seangeo about 6 hours later

      I think it woud be much better if only forks got the user name prepended but the “root” repository used just the name of the repository. It would at least fit with the current model better.

    • drnic about 7 hours later

      http://gems.github.com/ – says you need an explicit gemspec file. Why? Cool people don’t create manual gemspec files. Ok, I have no idea what cool people do, but I don’t create gemspec files. Hoe/Echoe do it at install time.

    • pjhyett about 8 hours later

      I’ve updated the post, turns out rubygems handles this namespacing issue beautifully (thanks to @nicksieger and @mislav for the solution).

    • evilchelu about 10 hours later

      If a gem has a binary file and you install different forks of it (evilchelu-foo, drnic-foo, foo), the binary in .gems/bin will get replaced by the last installed gem.
      Any hints on how this should be handled when creating the gem?

    • grempe about 11 hours later

      Thanks for this great feature. I think it will take some getting used for all of us getting our heads, and our code around the new distrubuted nature of gems.
      But look at all the rubyforge cruft that I was able to remove!
      http://github.com/grempe/amazon-ec2/commit/5b3a2c0ac915a75ed147c52d49c9e80f17cad295
      You also might want to take a look at my Rakefile and amazon-ec2.gemspec files for what I think is a nice DRY approach (feedback or improvements welcome).

    • thewoolleyman about 16 hours later

      Sweet! Thanks.

    • nullstyle 5 days later

      It would be great to have some indication of whether or not a gem was built successfully and is available to gem install.
      For example, http://github.com/nullstyle/test-spec/tree/master builds fine locally, but 24 hours later I’ve got no luck with gem install nullstyle-test-spec.

    Participate

    Please log in to comment.
rss