[Nix-dev] python application vs python environment

[Florian Friesdorf]

On Fri, 23 Sep 2011 23:27:40 +0200, Marc Weber <marco-oweber at gmx.de> wrote:
> Excerpts from Florian Friesdorf's message of Fri Sep 23 20:46:12 +0200 2011:
> > By wrapping the python interpreter (see pythonhomeWrapper) and setting
> > PYTHONHOME to the profile, this can be prevented and site-packages are
> > correctly available.
> Yes, but it won't work if you want to make configure scripts find
> dependencies unless you start building up temporary PYTHONHOME's for
> each build.

Could you provide an example for what would not work, ie. list of shell
commands to type to run into a problem.

> The better solution NIX_PYTHON_SITES patch has been implemented by me
> and some packages such as pygtk has been patched properly (not for 3.0
> though). Its like PYTHONHOME but supports multiple paths which requires
> some packages to be patched because they want to install into that one
> HOME.

Where is that patch?

> Eventually you should consider having a look at my work. Its not
> complete, But I'm pretty sure that it has some pretty nice ideas.
> For ruby I start building up environments for individual projects:
> ...
> The system is strong enough to not allow two versions of the same libraries to
> be put into the same env. It also resolves dependencies automatically.
> You can add version constraints eg force "savon == 3.2".
> 
> Needless to say that those envs also generate tag files for you automatically.

You are sketching a "system" that builds environments in contrast to
simple nix profiles, which does dependency resolution and creates tag
files. This sounds like interesting pieces of functionality. For me
personally, it would be great to see them as isolated (mostly
independent) patches/applications. I don't want to change nix, but make
its tools fulfill my and other python developers needs.

So, a resolver I see relevant to generate nix expressions (see other
thread currently running). Generation of tag files is something for a
development environment.

There is the concept of a profile in nix and I feel it important to have
a definition of how python behaves in such a profile. If a nix profile
is not suitable to generate a working python environment, than we should
have documented why not and why we do not intend to fix it and what to use
otherwise.

I think (for now): that

- a python and its modules installed in a profile should be a working
  python environment,

- python development tools (virtualenv, ipdb) installed into it should
  be using it,

- its possible to have multiple python versions in one profile

- python applications installed into the profile do not use the python
  environments of the profile but instead their own PYTHONPATH-isolated
  one.

> > Instead we need a python that stops resolving symlinks once it reached
> > its home profile (not continuing into its derivation).
> > 
> > A solution would be, not to link python and pythonX.Y from the
> > derivation, but instead to create two wrappers that set the PYTHONHOME
> > and call then the python in the derivation.
> I have to think about this. I won't have time within the next 8 days or so.
> 
> > How can I influence how a derivation is merged into another derivation?
> Not sure what you're referring to here.

When nix merges a derivation into a profile, all its files will be
linked to the profile. More specifically, if the derivation is the only
provider of a directory, the directory will be linked instead of
individually linking its contents.

If ./bin/python is a symlink, we have currently a problem and PYTHONHOME
would be a solution, if python is a real file, we do not have a problem.

So instead of symlinking the python executable, nix-env should be instructed
to hard-link it - is this possible?

regards
-- 
Florian Friesdorf <flo at chaoflow.net>
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo at chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110924/75b456be/attachment.bin