[Nix-dev] Re: Ruby-gems

[Bárður Árantsson]

Michael Raskin wrote:
> Bárður Árantsson wrote:
> |>> My problem is that I want to provide Ruby to biologists, and can not
> |>> support all GEMs they will think of.
> |>
> |> I still think that a wrapper that is a combination of Ruby plus all the
> |> gems you need for a certain package would be sufficient. Maybe we should
> |> just sit together for a few hours to just see if we can get it fixed
> |> without too much effort.
> |
> | The problem with executable wrappers is that the don't scale: You need a
> | wrapper for every conceivable combination of GEMs/Eggs/whatever... which
> | is impractical.
> 
> Well, you never need to have all wrappers created at once. You generally
> have no more than one per environment generated automatically, and that
> results in some sane amount of wrappers. Maybe add a few that are used
> internally in some builds.

Then I'm not sure I understand what is meant by a 'wrapper' in this 
case, but in f.ex. the case of python and bzr, we get a wrapper which is 
essentially

    bzr:
      #!/bin/sh
      PYTHONPATH=/nix/store/xxx-bzr/whatever/site-lib:$PYTHONPATH
      /nix/store/xxx-python/bin/python

(I don't have my NixOS install handy ATM, but so that's from memory, 
probably wrong on a few details.)

If you then install bzrtools (which integrates with bzr, NOT python per 
se), you'd need a new wrapper _for bzr_ along the lines of

    bzr:
      #!/bin/sh
      PYTHONPATH=/nix/store/xxx-bzrtools/whatever/site-lib:$PYTHONPATH
      /path/to/old/wrapper/bin/bzr

If you then have another plugin for bzr, you'd need yet another wrapper 
(but which wrapper get priority?). This seems to lead to a proliferation 
of wrappers if you have packages for e.g. python which integrate with 
each other.

If you do this purely with a 
"build-a-complete-environment-based-on-environment-bits-installed-by-packages" 
approach (cf. /etc/env.d in Gentoo) you don't get the same problem 
because packages just combine naturally without needing these executable 
wrapper scripts.

What I'm saying is that it might be more useful to have, say:

       ~/.nix-profile/env.sh:
           ...
           for x in ~/.nix-profile/env.d/*.sh; do
               source x
           done
           ...

    ~/.nix-profile/env.d/70-bzr.sh:
       PYHTONPATH=/nix/store/xxx-bzr/lib/python/site-lib/...:$PYTHONPATH

    ~/.nix-profile/env.d/80-bzrtools.sh:
 
PYHTONPATH=/nix/store/xxx-bzrtools/lib/python/site-lib/...:$PYTHONPATH

    ~/.nix-profile/env.d/80-bzr-svn.sh:
       PYHTONPATH=/nix/store/xxx-bzr-svn/lib/python/site-lib/...:$PYTHONPATH

The user just says

      source ~/.nix-profile/env.sh

and everything Just Works(TM). I should note that most of the 
information needed to build these files (or a functional equivalent) 
already exists in the Nix packages -- the package dependencies give the 
prioritization.

I'm aware that the bzrtools package doesn't actually do this and that 
the user instead has to manually add the bzrtools directory to the 
python search path (either by a "magic" symlink or PYTHONPATH), but it 
sure would be nice if this kind of thing just worked out of the box.

(Btw, I really don't mean to hijack the thread with stuff about python 
and bzr, so I'll try to refrain from posting more to this thread. I just 
thought that it might be interesting to look at how this might be solved 
generally rather than only for ruby. I don't know enough about ruby/ruby 
gems to know whether any of this applies there.)

Cheers,

-- 
Bardur Arantsson
<bardurREMOVE at THISscientician.net>

- The greatest trick the devil ever pulled was convincing the
world he didn't exist.
                                  Verbal Kint / The Usual Suspects