[Nix-dev] How are perl modules handled?

[Marc Weber]

Excerpts from Tobias Hunger's message of Sun Feb 27 21:50:54 +0000 2011:
> Hi there!
> 
> I am having some trouble understanding how nixos handles perl module 
> installations. Other scripting languages like python and ruby are most likely 
> handled in a similar way.
> 
> Perl is installed in /nix/store/hasha-perl-5.10.1/...
> A random perl module is installed into /nix/store/hashb-moduleB-0.8.15/...
> ~/.nix-profile merges those into one view of the system... which should allow 
> programs using moduleB to function.

Have a look at buildPerlPackage.

If you have a look at both: perl-packages.nix and the builder.sh file of
buildPerlPackage you'll notice that propagatedBuildInputs is used which
is then written to $out/nix-support/propagated-build-inputs and
propagated-user-env-packages ensuring that dependencies are always added
as well.

Don't miss setup-hook.sh which will make the default builder add the .pl files to the
search path:
pkgs/development/interpreters/perl-5.10/setup-hook.sh

About Ruby: I did the initial work on it. However I abandoned it in
favour of the nixpgks-ruby-overlay (see my git repos). I wrote about it
in the mail talking about my work some days ago.

Support is pretty good. It even fails if two libraries depend on
different versions of the same ruby library. I still have to fix
ruby-debug libraries for ruby-1.9

For python: current support in nixpkgs is available but I feel that
using PYTHONPATH  only is not enough - that's why I also maintain a
private branch using an alternative implementation until I find more
evidence for it. Eg .pth files are not treaded correctly.
Also for my taste the pygtk implementation symlinking gtk-2.0/* to
out/lib is too hacky. I've hit some cases where it didn't work for me.
However wicd etc runs fine..

I'm working on a nixpkg-python-overlay importing all pypi packages.
package import works but I still have to find out about dependencies and
write all the nix code handling it.

> So how does nixos make sure that hashb is only used with the hasha version of 
> perl?
.. It only depends on PERL5LIB. And probably using this env var is best
you can do. I don't know perl very well.
 
> Should it unlink hashb from the user environment once updating it to use 
> hashc-perl-5.10.1?
.. Depends on your use cases. grep nixpkgs for PERL5LIB and you'll
notice that a common solution is to wrap executables defining a PERL5LIB
env var for each executable so that they work without installing libs to
your user env profile.
Eg have a look at slimrat. If you install it into your user profile it
does not also pull WWWMechanize.

Was this reply comprehensive enough?

Marc Weber