-
-
Notifications
You must be signed in to change notification settings - Fork 491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Meta-ticket: ./configure --enable-system-site-packages (optionally use system Python packages) #29023
Comments
comment:1
I think there should be an option to disable the use of system packages. Sage's installation is already compilcated enough and I don't want a faulty package to mess up sage. |
comment:2
You can already do |
comment:3
I just found out about the ./configure --help option. --with-system-python3 is actually exactly what I meant. |
This comment has been minimized.
This comment has been minimized.
comment:5
Replying to @Volker-Weissmann:
Thanks for the input. I've updated the ticket description. |
This comment has been minimized.
This comment has been minimized.
comment:7
I think once python system packages are detected, the spkg-configure mechanism becomes interesting for packagers. Looking forward to this change. |
comment:8
I don't think python packages would be handled through spkg-configure. |
comment:9
I tried to create an experimental |
comment:10
If you take look at sage-env you see the line PYTHONUSERBASE="$DOT_SAGE/local" but I think it should be PYTHONUSERBASE="$SAGE_ROOT/local" , because (at least on my machine) the folder $DOT_SAGE/local does not exist. |
comment:11
The way to enable system site packages is to use Using PYTHONUSERBASE is not a suitable way forward. |
comment:12
(And neither is an ad-hoc modification of PYTHONPATH proposed in #29665.) |
comment:13
Replying to @Volker-Weissmann:
Users create this folder if they want to install user packages, for example using |
comment:14
Ok. Thank you. I thought it was a bug. But this means that if you run sudo pip uninstall cython cou can't build sage. |
comment:15
Well, isolating the Sage user installation scheme from the Python user installation scheme was done deliberately in the past to avoid possible breakage by incompatible installations. This decision may have to be revisited at some point, but I don't think it's necessary for this ticket. Sage's install scripts will continue to make sure that the Sage venv has all necessary packages - whether user of system site packages is enabled or not. |
comment:16
Just a quick note that I plan to work on this for Sage 9.3, not earlier. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
comment:19
Replying to @mkoeppe:
It's not always easy to know what the programmers thought. What is the best source to learn things like this? Reading the tickets? |
comment:20
That, and asking questions on the sage-devel list, I suppose. |
comment:21
In the case of PYTHONUSERBASE, comments in sage-env point to some relevant tickets. |
comment:22
Thank you. |
This comment has been minimized.
This comment has been minimized.
Changed dependencies from #27824 to none |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
comment:34
Setting new milestone based on a cursory review of ticket status, priority, and last modification date. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I wish https://github.com/sagemath/sage/actions had CI Linux system-site-packages workflow next to CI Linux |
This is a followup on #27824:
spkg-configure.m4
for python3.In the next step, we make it possible for users to enable use of system Python packages (site packages).
It is crucial to distinguish two categories of Python packages.
A. Python-implemented applications not running in the same process as sagelib
For some specific packages that provide Python-implemented applications and do not run in the same process as
sagelib
, there are separate tickets that may usespkg-configure.m4
notebook
(System package information, spkg-configure for Jupyter "notebook" package, "rst2ipynb", and dependencies #30124),rst2ipynb
, and their dependencies.'''B. Packages that run in the same process as sagelib.``
Use of these packages would be enabled by a new configure option
--enable-system-site-packages
.This will set up the venv using
build/bin/sage-venv --system-site-packages
Approach 1:
configure --enable-system-site-packages
viaspkg-configure.m4
Approach 2:
Separate the installation process of a Python package into several phases (makefile targets):
i) Downloading the spkg tarball (in most cases the tarball will already be an sdist, i.e., with embedded metadata)
ii) (When patches are needed or the upstream tarball is not a real sdist:) Unpack, patch, make a new sdist
iii) Copy the sdist to
$SAGE_SPKG_WHEELS
or a new directory next to itiv) Build a wheel and copy to
$SAGE_SPKG_WHEELS
v) Install the wheel
Questions to be resolved:
#32492 comment:17 -- installed packages are only considered by pip if they can also be found in an index. As we use
--no-index
, the workaround in sage-pip-install: Try installing without --no-deps first #32492 provides the directory$SAGE_SPKG_WHEELS
as the index.To be checked if the specific installed version of the package needs to be found in the index. If presence of any version (= spkg version) will cause pip to consider the installed version as a candidate for resolution, then we can just leave the decision whether to use the installed package or the spkg to the resolver and the pip upgrade-strategy.
If a package needs any special preparation for building a wheel such as setting of environment variables, we need to:
a) either invoke phase iv) explicitly (so wheels of such packages may be built but remain unused);
b) or try to move the environment settings to the general build environment;
c) or patch the Python package's build script instead, treating it like phase ii).
If we need a specific version (with patches that have not been upstreamed), should this be reflected in dependency information (
install-requires.txt
)?Investigate pip's and other tools behavior when installing an upgraded/downgraded version of a package in the venv when the package is installed in the system site packages
Related/follow-up tickets:
./bootstrap
time, generaterequirements.txt
,constraints.txt
,setup.cfg [install_requires]
,Pipfile
frombuild/pkgs
src/requirements.txt
andsrc/setup.cfg [install_requires]
for installation ofsagelib
in a venvsagelib
in a venvTickets/issues for individual packages (moved here from #27330, will be obsolete with this ticket):
References:
https://packaging.python.org/discussions/install-requires-vs-requirements/
PEP 508 -- Dependency specification for Python Software Packages | Python.org
https://www.python.org/dev/peps/pep-0508/#pep440
PEP 440 -- Version Identification and Dependency Specification | Python.org
https://www.python.org/dev/peps/pep-0440/#local-version-segments
https://python-poetry.org/docs/pyproject/#dependencies-and-dev-dependencies
CC: @tobihan @sagetrac-tmonteil @orlitzky @timokau @kiwifb @isuruf @mezzarobba @embray @dimpase @thierry-FreeBSD @dkwo
Component: packages: standard
Issue created by migration from https://trac.sagemath.org/ticket/29023
The text was updated successfully, but these errors were encountered: