[Nix-dev] nix + rubygems + sinatra

[Isaac Dupree]

Pjotr Prins wrote:
> On Mon, Mar 02, 2009 at 07:17:59PM -0800, Jim Pick wrote:
> > I'd actually like to come up with an automated way of generating nix
> > expressions from Ruby gems, if that is possible.
>
> There are several possibilities to package gems for Nix (likewise
> eggs for Python and packages for R, Perl etc.).

> 1- Generating Nix expressions from gem definition - like you have
> done really using a wrapper:
> ...
> 	  - Con: potentially lots of work for every dependency
> 		- Con: problems with non-pure Ruby gems
> 		- Con: maintenance nightmare for thousands of gems (BAD)

For Haskell "Cabal" system, there is automation like this where Don Stewart 
maintains about a thousand Haskell packages for Arch Linux without difficulty.  
Many of them bind to C libraries.

But it could well be that other languages' packaging systems don't give us 
enough metadata to work with, or are just deficient in other ways (that we 
might or might not be able to improve).

hmm, is it sensible to have a single nix expression that, given the right 
arguments, installs any ruby-gem? (since because nix is functional language, 
I'm tempted to say "use functions!" but that may be complicated and not 
sensible).

> 2- Installing gems in user land (current 'solution')
>     - Pro: gems are installed in ~/.gems with user permissions
> 		- Con: no version control (BAD)
> 		- Con: no conflict control (hey, we are Nix, right?!)

Pro: Fugitive from other bad distros knows it still works on Nix, even if it 
isn't the optimal solution

Con: User can't install *anything* globally that depends on any Ruby library, 
program, etc.

> 3- Have gem work with ruby in Nix profile (current 'solution')
>     - Pro: works with right installation permissions
> 		- Con: makes Nix Ruby package inconsistent - package installs in
> 			Ruby directory /nix/store/ruby-afd980... (BAD)
>
> 4- Change 'gem' package controller to support Nix
>     - Pro: support 'gem install package' out of the box

because "gem" has "install globally / as root" feature, and we'd like to 
support it, and we are opposed to installing in some fixed location like 
/usr/local because it causes all those problems that Nix is meant to 
alleviate.  (It's not a new feature that'd be completely out-of-place in that 
third-party software, that is.)

> 		- Pro: automatically creates a Nix package for every gem
> 		- Pro: automatically share compiled gems
> 		- Pro: automatically support multiple Rubies (1.8, 1.9)

big plus.

> 		- Con: we need to hack and maintain the gem code

some of it can probably be sent to upstream, at least when it would help other 
distros integrate "gem" as well

> 		- Con: this needs to be done for eggs, R, cpan etc.

we'll need to do something with each of them, anyway

> Personally I think (4) is really the way to go. Not easy, but
> supporting existing gems will make Nix user friendly for everyone
> using Ruby gems and provide a consistent state. I'll be happy to help
> out moving this along.

we'll have to see how much it is possible to automate all that from the 
information in the existing package collections (e.g. they may not declare 
their dependencies very well).  Sometimes working with upstream community will 
be more effective than others.

-Isaac