Opened 3 years ago

Last modified 3 years ago

#21456 new defect

revert #19612 -- don't mess with PYTHONUSERBASE at all.

Reported by: was Owned by:
Priority: major Milestone: sage-7.4
Component: packages: optional Keywords:
Cc: Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

I personally disagree with trying to make Sage's python and the general environment be as isolated as possibly from each other. We should try to interoperate with the greater Python world as much as possible, not change things to discourage that. If you want total isolation, use Docker, don't mess with environment variables like this...

I realize that this might just get closed due to philosophical differences. How about just document PYTHONUSERBASE in our FAQ or something (like it is in python) and trust users to have a clue?

Change History (4)

comment:1 Changed 3 years ago by jdemeyer

Perhaps you should post to sage-devel about this ticket? The change is trivial to make (and I agree with it) but I think that other people should be able to give their opinion.

comment:2 Changed 3 years ago by was

Good idea -- done.

comment:3 Changed 3 years ago by nbruin

In order to see what the ramifications are: if I'm not mistaken, the main effect that PYTHONUSERBASE has is that if $PYTHONUSERBASE/lib/python2.7/site-packages exists, then it's added to sys.path and used for module lookup. Furthermore, if on a unix machine the variable PYTHONUSERBASE doesn't exist then the value $HOME/.local is used.

As you can see, python gets around the problems of the possibility of multiple incompatible python versions by including the version number in the path name.

Clashes could occur if for a package python setup.py install --user is run, or sage -python setup.py install --user.

The problem is that the system python2.7 and sage's python2.7 are linked against significantly different libraries and hence are quite possibly incompatible: packages installed for one may not be able to run on the other.

Particularly, a user who wants to install a package (that is sensitive to some of the linking differences) in both the system python and the sage python would probably think that running both install --user commands would get the desired result. It does now. If we do not change PYTHONUSERBASE the user would need to learn about PYTHONUSERBASE and set it in sage to be able to use both.

(or have write permission on the sage install so that he/she doesn't have to include the --user option for the sage install, and hope that the system python will pick up its own version before the one reachable via PYTHONUSERBASE).

It would suggest to me that we shouldn't particularly be messing with the value of PYTHONUSERBASE but may want to build the sage python with version python2.7.sage to distinguish it from the system python. It could be that there are too many locations where that would lead to other problems, though.

Eventually it would be nice if sage could really just be installed as a python package in the system python, of course, but we're not there yet. If we could build the "sage specific" python with a separate version identifier it might help with the migration at some point.

comment:4 Changed 3 years ago by embray

Could someone clarify exactly what it is that Sage is doing with $PYTHONUSERBASE? And is it something sage the library is doing, or something that sage-env is doing?

Note: See TracTickets for help on using tickets.