Opened 4 years ago

Closed 4 years ago

#19612 closed enhancement (fixed)

Use PYTHONUSERBASE

Reported by: was Owned by:
Priority: major Milestone: sage-6.10
Component: misc Keywords:
Cc: dunfield, vbraun Merged in:
Authors: Matthias Goerner Reviewers: Volker Braun
Report Upstream: N/A Work issues:
Branch: 813862a (Commits) Commit: 813862ad6a89de8a0559a9d6da693bab07fb511d
Dependencies: Stopgaps:

Description (last modified by vbraun)

Use PYTHONUSERBASE instead of PYTHONNOUSERSITE

Change History (15)

comment:1 follow-up: Changed 4 years ago by fbissey

Suggestion: #14243 was originally included to avoid interference from installation done outside of sage. Something SMC and sage-on-gentoo don't really have to worry about. A middle ground could be to have sage's python to look for user installed packages in DOT_SAGE/site-packages.

comment:2 in reply to: ↑ 1 Changed 4 years ago by was

Replying to fbissey:

Suggestion: #14243 was originally included to avoid interference from installation done outside of sage.

I realize that. Yet how many people reported problems with this -- one over 10 years? I think we should revert #14243, and instead just add something to the FAQ about export PYTHONNOUSERSITE=yes. If somebody really does have ~/.local/ stuff that is interfering with sage's python, they could set export PYTHONNOUSERSITE=yes themselves easily enough.

comment:3 Changed 4 years ago by dunfield

I agree with William that #14243 was a mistake. I make heavy use of the user site-packages directory when working with Sage, so #14243 causes a lot of problems for me. I think it would be great to revert #14243 now, hopefully making it into Sage 6.10.

In the long term, having Sage's user site-packages be in a nonstandard location (for example DOT_SAGE/site-packages as suggested above) has no negatives that I can see and would make things more robust in certain cases. On OS X, this is already effectively the case, since any frameworks build of Python (e.g. the system Python or the one from Python.org) uses ~/Library/Python/2.7/lib/python/site-packages rather than ~/.local/lib/python/site-packages as the default user site-packages directory.

comment:4 Changed 4 years ago by dunfield

  • Cc dunfield added

comment:5 Changed 4 years ago by jhpalmieri

I don't object to reverting #14243. One disadvantage to putting Sage's packages in a non-standard location is that users might need to install them twice: once for the system Python and once for Sage. This would not be what people expect. I don't know that much about the Python packaging system; can we have Sage's Python look in several different places for packages ($DOT_SAGE/site-package and also unless some Sage-specific environment variable is set, ~/.local/lib/python/site-packages and/or ~/Library/Python/2.7/lib/python/site-packages)?

comment:6 Changed 4 years ago by novoselt

I am not affected by this exact issue, but pretty much the same one had to be dealt with for enabling R plotting in SageMathCell. So I am of the opinion that Sage should not interfere with users trying to install extra packages (or config files) for its components. For collisions happening because of this, it would be nice to have clear instructions on how to proceed, but no need for silent preventive actions.

comment:7 Changed 4 years ago by mgoerner

  • Branch set to u/mgoerner/pythonuserbase

comment:8 Changed 4 years ago by mgoerner

  • Authors set to mgoerner
  • Commit set to 813862ad6a89de8a0559a9d6da693bab07fb511d
  • Status changed from new to needs_review

New commits:

813862aFixing http://trac.sagemath.org/ticket/19612 by setting PYTHONUSERBASE to ~/.sage/local instead of setting PYTHONNOUSERSITE=yes.

comment:9 Changed 4 years ago by kcrisman

  • Cc vbraun added

comment:10 Changed 4 years ago by vbraun

  • Description modified (diff)
  • Reviewers set to Volker Braun

comment:11 Changed 4 years ago by vbraun

  • Description modified (diff)

Author name must be real name

comment:12 Changed 4 years ago by vbraun

  • Summary changed from revert 14243 to Use PYTHONUSERBASE

comment:13 Changed 4 years ago by mgoerner

  • Authors changed from mgoerner to Matthias Goerner

comment:14 Changed 4 years ago by dunfield

  • Status changed from needs_review to positive_review

Tried it out, and it works as advertised. Setting status to positive review.

comment:15 Changed 4 years ago by vbraun

  • Branch changed from u/mgoerner/pythonuserbase to 813862ad6a89de8a0559a9d6da693bab07fb511d
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.