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
<[EMAIL PROTECTED]>
- The greatest trick the devil ever pulled was convincing the
world he didn't exist.
Verbal Kint / The Usual Suspects
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
