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:
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!
Mad props.
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:
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?
@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.
@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
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”?
@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.
@rtomayko the expectation is the that dependencies would now use ‘mojombo-foo’. After all, that’s the new identifier for the gem.
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?
jonner: We offer many features only a subset of our userbase wants or is able to take advantage of.
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.
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.
I’ve updated the post, turns out rubygems handles this namespacing issue beautifully (thanks to @nicksieger and @mislav for the solution).
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?
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).
Sweet! Thanks.
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.
I think the concept of naming every gem with a person / account is a mistake. Does this mean for example that rails and all associated gems will become rails-rails and rails-activerecord (the 1.8 million references in google will just have the change!) It also means that every time a project is handed from one owner to another the name will change. So I have to change requires in my code just because someone new has taken over a project? I think the idea of lots of people working on projects, forking, merging and creating better stuff is great, but without a clear constant name for any particular piece of code and it’s reference or trunk implementation, the management of that code out into the community (especially those of us that use it in commerical day to day environments) will be painful. Instead, why not allow the originator to have the unadorned name and then require forks to prepend their name. Of course you’d also have to have a way to someone to “give” the name to another contributor when they hand over development. Another consequence of the current approach is that rails (and ruby) become just that much more opaque to new users who are confronted with an array of choices for a gem.
ok – disregard part of my off the cuff comments above (cue emily litella)- I get it now that the require has some magic and I DON’T have to change my code at that level, I just need to know who’s name to use to find the gem. So really I only have to deal with the namespace when installing the gem on my system which I have to admit is reasonable. thanks!
But I can’t click on the graphic or the file name to jump to the submodule page and downloading the tarball for the project doesn’t include the submodule files Phd degree AND foundation degree AND online MBA degree
This is the production version of the BMW 5 Series GT. Doesn’t look a lot different to the Concept Gran Turismo shown at Geneva. Quelle surprise online Master degrees AND Online degree programs
For information and products relating to height increase or footcare please visit HEELSNCLEAVAGE
Thats great, Ive messed around with Zookeeper a few times
HEEL PADS
SHOE INSOLE
INCREASE MY HEIGHT
INCREASE YOUR HEIGHT