On 12/07/2016 06:21 PM, Stephen John Smoogen wrote:
On 7 December 2016 at 10:27, Tomas Orsava <tors...@redhat.com> wrote:
On 12/07/2016 01:56 PM, Neal Gompa wrote:
On Wed, Dec 7, 2016 at 7:53 AM, Michal Cyprian <mcypr...@redhat.com>
wrote:
- system-python (i.e. what all programs installed via DNF will use) is
limited to site-packages under /usr, so DNF-installed software is unaffected
by anything installed with pip
system-python is not intended for this use-case. It was designed to
support DNF itself and other related system software. It's also
intentionally set up to not have everything that regular python3 has.
I would really hesitate to allow this to be used for more than that,
because then we're back to square one, again...
I think there's been a slight miscommunication: system-python will be used
instead of python3 only when building/installing packages inside spec files.
The built packages themselves depend on will be run by python3.
There has been some sort of miscommunication because from my layman
take on things, what Neal was what system-python was only meant to be
used for .. for exactly the reason he said.
System-python is a rather complex and evolving topic, so let my try to
explain it a bit deeper (as I understand it):
Up to this proposal, the system-python binary
(/usr/libexec/system-python) has been simply a direct copy of the
python3 executable (/usr/bin/python3{,.5}) [0]. The usefulness of
system-python thus does not come from the executable you use, but from
the `system-python` package that contains it. The difference between the
`python3` and `system-python` packages is that the former requires the
full Python 3 standard library (package `python3-libs`), whereas the
`system-python` package requires only a smaller subset thereof (package
`system-python-libs`). Thus saving space when Python is only needed for
system tools.
This proposal constitutes a second evolutionary step of system-python:
We now want to slightly modify how the two executables behave. Python 3
will continue as it always has—you will be able to import modules
whether you installed them through dnf or pip/setuptools. Contrary to
that, system-python will become more limited: It will only recognize
Python modules installed through dnf, and as a result, your system tolls
(dnf et al.) will become impervious to problems stemming from
non-functional/problematic modules installed using sudo pip, which up to
now could simply overwrite crucial modules installed by dnf.
To implement this modification, the locations of dnf-installed and sudo
pip–installed modules need to be separated. The default location where
Python decides to install new modules is contained within the
executable, and thus Python 3's install location will be the one where
sudo pip–installed modules belong, while system-python will install
modules to a path where dnf-installed modules ought to go. Therefore if
you run sudo pip, Python 3 executable will be invoked and pip will
install modules to the appropriate place. And in spec files of Python
RPM packages, the %{__python3} macro will be modified so that
system-python is invoked instead, and the modules will be installed to
the appropriate location for dnf-installed modules.
A good question to ask at this point is: Is it ok to use system-python
in spec files like this when it requires only a limited subset of the
Python 3 standard library? The confusing part is that while
system-python requires only a limited stdlib, it will use the full
standard library if it is installed. And when it comes to Python RPM
packages, it will always be installed because: 1. At build time all
Python 3 packages have to use `BuildRequires: python3-devel` which
brings in a full stdlib complement, and 2. at run time the resulting RPM
packages will depend on the `python(abi) = 3.X`, which is only satisfied
by the `python3` package and it's full stdlib.
I hope this may shine a bit of light on the issue.
[0]
http://pkgs.fedoraproject.org/cgit/rpms/python3.git/tree/python3.spec?id=ddb16c68d95603cc11233c520544adf92c3741fe#n1061
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
