@cillianderoiste: Sorry for not making myself clear. I'll try again.

What I meant was that if the idea of "activating" things in the profile (by default) is considered dangerous, then the solution would be (to take it to the extreme) to say that the shell doesn't have access to any other commands either, other than load-env-foo commands. So, to use SCM tools, you'd have to make your own environment for e.g. git and mercurial and load-env-scm to use them. And if you want to look at photos or listen to music, you'd have to load-env-music or load-env-photo.

But I think we can both agree that this is pretty cumbersome!

NixOS currently "activates" lots of stuff, for example bin/, lib/mozilla/plugins/ and lib/perl5/site_perl/* (see /modules/programs/bash/profile.sh). But all (wrapped) programs have the ability to put these paths first, last or be completely ignored. We don't need to do anything special, it's already possible to do that. So, to some extent, I think we can say that if a program breaks because of something being installed in a user profile, it is a bug in that program/wrapper (because the wrapper can ignore those paths, if it wants to, or it can put those extra paths at the very end of its search path so that all non-optional dependencies are found in the right place and not overridden with stuff from the environment).

I think the main issue with these global environment variables is that they are not versioned. For example, GST_PLUGIN_PATH is probably read by both gstreamer-0.10.x and 1.0.x. And I'm pretty sure that a plugin written for 0.10.x will crash in 1.0.x.

But at least with Python I think we can do better. I'm currently experimenting with loading paths from PYTHONPATH, by extending sitecustomize.py in the recursive-pth-loader thing.

# Append paths from PYTHON<VERSION>PATH environment variable to sys.path
pythonpath = os.getenv("PYTHON%d%dPATH" % (sys.version_info.major, sys.version_info.minor))
if pythonpath:
    sys.path.extend(pythonpath.split(os.pathsep))

AFAIK, normal wrapped python programs use pkgs.python and that python doesn't use recursive-pth-loader. But pkgs.pythonFull and pkgs.ipython do use it, so they will automatically pick up the python modules from the profile. (Of course, a wrapped python program can use pkgs.pythonFull if it wants.)

For NixOS, I'm thinking of exporting PYTHON{26,27,32,33}PATH with value $PROFILE/lib/pythonVERSION/site-packages, for PROFILE in system_profile, default_profile and user_profile, similarly to what is done with PATH, PERL5LIB and all other environment variables used to "activate" stuff from profiles.

What do you think of PYTHONPATH?

Uh oh!

how to customize modules available to ipython? #64

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions