requirements for native gems not free text?

Jordi Massaguer Pla jmassaguerpla at
Wed Jan 30 11:10:10 UTC 2013

> Josiah and I had a system which was a small service and gem plugin  
> that mapped dependency+version (provided via the metadata facility)  
> to a platform-specific set of packages. Then based on the  
> user-selected or detected platform it would install those packages,  
> elevating privileges if necessary. It would then finish the gem  
> installation which at that point should work no differently than it  
> does now.
> Hooks have been in rubygems that can make this work since 1.6 or so  
> (and I believe this was around the time we came up with this idea).  
> Someone just has to write it. That someone will likely not be Josiah  
> or myself, but I'll be happy to detail this for anyone that's  
> interested in building such a thing. It's not very complicated and  
> there's a little code out there, but not much; I think it was  
> written at the last philly.rb we both attended which was around 2  
> years ago, but it's a simple enough idea to get your head around  
> regardless.
> Metadata is arguably the perfect place for this for the reasoning I  
> try to provide above. Third party tools can support it, devs can use  
> those third party tools, and production systems don't have to if  
> they don't want to. If you want a fancy DSL, I don't think anything  
> keeps you from subclassing Gem::Specification.

I agree. The missing piece is some kind of convention or  
recommendation on the metadata, so that I do not have to fork every  
native gem I plan to use and maintain them on my own but I can send a  
Pull Request instead and have some possibilities that the owner  
accepts that.

Which metadata key and values were you using or would you suggest?

> It was geared towards developers. Making rubygems or mkmf satisfy  
> system dependencies as a first class feature would make writing  
> replacements for both a very appealing topic for sysadmins that have  
> to support ruby stacks and don't work around both already.
> -Erik
> _______________________________________________
> RubyGems-Developers mailing list
> RubyGems-Developers at

More information about the RubyGems-Developers mailing list