6:13 a.m.
Forwarding to fedora-devel as well
Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat
----- Original Message -----
From: "Michal Cyprian" <mcyprian(a)redhat.com>
To: python-devel(a)lists.fedoraproject.org
Sent: Wednesday, April 26, 2017 11:19:00 AM
Subject: What is your opinion on "sudo pip" fix for Fedora 27?
At the present time, running sudo pip3 in Fedora is not safe.
Pip shares its installation directory with dnf, can remove
dnf-managed files and generally break the Python 3 interpreter.
Our first attempt to make sudo pip safe on Fedora [0] was
based on using a different binary (/usr/libexec/system-python)
for RPM packaging purposes and changing the behavior
of /usr/bin/python3 (and pip that uses its settings) to install
under /usr/local by default. Switching all the Python 3 packages
to system-python turned out to be much more problematic than
expected and we had to postpone the Change for F27.
We decided to try a different approach. The main idea is to detect
an ongoing RPM build and modify the behavior of the Python 3
executable only when in normal user environment so that RPM builds
won't be affected at all.
The adjustment of the behavior can be done on different levels.
The first option is to set the sys.prefix variable to /usr/local
when the interpreter is initialized. This will affect
all the install methods, but the solution can cause some
problems in applications that rely on the value of sys.prefix.
A prototype of this implementation can be seen here [1].
The other possibility is to limit the pip install location change
to distutils and pip [2]. This is the "safer" option, but does
not cover all corner cases. For example, Python software built
locally using cmake or similar tools will be installed into
/usr/lib and can conflict with system tools. Debian chose to
implement similar solution.
I would like to ask which solution would work for your applications
better, and what is in your opinion the right way to go. I will
appreciate any costructive comments or ideas on how to improve these
patches. If you want to check some specific use-case you can use the images
docker.io/mcyprian/sudo_pip_sys_prefix and
docker.io/mcyprian/sudo_pip_install_prefix
to try out the two mentioned implementations.
[0]
https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe?rd=User:Torsa...
[1] https://github.com/mcyprian/python3/commit/6077c96460c03ddc334bae654fffcc...
[2] https://github.com/mcyprian/python3/commit/ac2f266a90871d67ba8d0b70d2b0eb...
Michal Cyprian
_______________________________________________
python-devel mailing list -- python-devel(a)lists.fedoraproject.org
To unsubscribe send an email to python-devel-leave(a)lists.fedoraproject.org
11:30 a.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
Our first attempt to make sudo pip safe on Fedora [0] was
This seems to be using "Fedora" to mean a *host* system, and
I'd agree there. I'll note as an aside that the other host system
management tool we use in Fedora is rpm-ostree, part of
Atomic Host: https://github.com/projectatomic/rpm-ostree
Due to the read-only bind mount over /usr provided by the ostree layer,
pip fails today:
# rpm-ostree status
State: idle
Deployments:
● fedora-atomic:fedora-atomic/25/x86_64/docker-host
Version: 25.89 (2017-03-26 21:04:50)
Commit: 6a71adb06bc296c19839e951c38dc0b71ee5d7a82262fef9612f256f0c2a70da
OSName: fedora-atomic
# pip install markdown2
...
error: [Errno 30] Read-only file system:
'/usr/lib/python2.7/site-packages/markdown2.py'
Which is expected, and IMO a good thing. (Although I'm a bit
surprised that we ship /usr/bin/pip in AH...but that's another issue)
Now, I myself use `sudo pip install` in some of my *containers*.
And if something were to break there, it's much less of a big deal,
I tend to recreate them from scratch periodically anyways.
1:40 a.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On 27 April 2017 at 02:30, Colin Walters <walters(a)verbum.org> wrote:
I'll note as an aside that the other host system
management tool we use in Fedora is rpm-ostree, part of
Atomic Host: https://github.com/projectatomic/rpm-ostree
Due to the read-only bind mount over /usr provided by the ostree layer,
pip fails today:
# rpm-ostree status
State: idle
Deployments:
● fedora-atomic:fedora-atomic/25/x86_64/docker-host
Version: 25.89 (2017-03-26 21:04:50)
Commit: 6a71adb06bc296c19839e951c38dc0b71ee5d7a82262fef9612f256f0c2a70da
OSName: fedora-atomic
# pip install markdown2
...
error: [Errno 30] Read-only file system:
'/usr/lib/python2.7/site-packages/markdown2.py'
Which is expected, and IMO a good thing. (Although I'm a bit
surprised that we ship /usr/bin/pip in AH...but that's another issue)
It's an artifact of the way that Fedora implements the standard
library's `venv` module without bundling a second copy of `pip` inside
the `python` package: instead there's a circular runtime dependency
between `python` and `python-pip`, and the venv module is patched to
convert the system level pip back into a wheel archive, which it then
installs into the created virtual environments.
It's definitely not pretty, but it works.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
8:47 p.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On Wed, Apr 26, 2017 at 7:13 AM, Charalampos Stratakis
<cstratak(a)redhat.com> wrote:
Forwarding to fedora-devel as well
Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat
----- Original Message -----
From: "Michal Cyprian" <mcyprian(a)redhat.com>
To: python-devel(a)lists.fedoraproject.org
Sent: Wednesday, April 26, 2017 11:19:00 AM
Subject: What is your opinion on "sudo pip" fix for Fedora 27?
At the present time, running sudo pip3 in Fedora is not safe.
Pip shares its installation directory with dnf, can remove
dnf-managed files and generally break the Python 3 interpreter.
This is true of every version of pip, not merely pip3. It was also
true of CPAN, and of many gradle, maven, and ant working environments
that semi-randomly collate the very latest versions of indeterminate
components and spray them on top of your system workspace with their
own quite distinct ideas about packaging and versioning.
There is no solution to this problem, except to use tools like
"pyvenv" to set aside secluded workspaces for Python modules and their
dependencies assembly. So, for most developers, they *should not* use
"sudo pip". They should remain in user space, or possibly in shared
workspaces, to avoid overwriting system components.
Our first attempt to make sudo pip safe on Fedora [0] was
based on using a different binary (/usr/libexec/system-python)
for RPM packaging purposes and changing the behavior
of /usr/bin/python3 (and pip that uses its settings) to install
under /usr/local by default. Switching all the Python 3 packages
Oh, Oh my. The extent to which this unworkable is... fascinating. You
will inevitably install incompatible future versions of critical
packages which are incompatible with the Fedora system packages. And
as soon as you install one that breaks RPM, if /usr/local/ if ahead of
/usr in your search path for modules, you are *screwed*. And if
/usr/local is first, well, an RPM update may introduce a component
that is incompatible with the pip installed modules at arbitrary
times.
to system-python turned out to be much more problematic than
expected and we had to postpone the Change for F27.
Sorry, no surprise there.
We decided to try a different approach. The main idea is to detect
an ongoing RPM build and modify the behavior of the Python 3
executable only when in normal user environment so that RPM builds
won't be affected at all.
See https://xkcd.com/1172/ . You're inventing a workflow that isn't
supported by *anyone*.
The adjustment of the behavior can be done on different levels.
The first option is to set the sys.prefix variable to /usr/local
when the interpreter is initialized. This will affect
all the install methods, but the solution can cause some
problems in applications that rely on the value of sys.prefix.
A prototype of this implementation can be seen here [1].
I'm sorry, but.... ouch. Please stop trying to implement "pip install"
as a system installation tool. The effort would be better spent
upgrading and enhancing "py2pack".
The other possibility is to limit the pip install location change
to distutils and pip [2]. This is the "safer" option, but does
not cover all corner cases. For example, Python software built
locally using cmake or similar tools will be installed into
/usr/lib and can conflict with system tools. Debian chose to
implement similar solution.
It's local environment specific, unstable software sensitive to
arbitrary and unmanaged upstream dependency updates, and extremely
sensitive to local system pip modules. It *does not belong* in
/usr/lib. Because the components are modular and bundled in a non-RPM
compatible fashion, it behooves developers to use a tool to segregate
the tools as much as feasible from the Fedora underlying
infrastructure. i.e., use pyvenv to build them in a contained
environment segregated from the system files.
> I would like to ask which solution would work for your applications
> better, and what is in your opinion the right way to go. I will
> appreciate any costructive comments or ideas on how to improve these
> patches. If you want to check some specific use-case you can use the images
> docker.io/mcyprian/sudo_pip_sys_prefix and
> docker.io/mcyprian/sudo_pip_install_prefix
> to try out the two mentioned implementations.
>
> [0]
https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe?rd=User:Torsa...
> [1]
https://github.com/mcyprian/python3/commit/6077c96460c03ddc334bae654fffcc...
> [2]
https://github.com/mcyprian/python3/commit/ac2f266a90871d67ba8d0b70d2b0eb...
>
> Michal Cyprian
> _______________________________________________
> python-devel mailing list -- python-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to python-devel-leave(a)lists.fedoraproject.org
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
1:32 a.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On 27 April 2017 at 11:47, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Wed, Apr 26, 2017 at 7:13 AM, Charalampos Stratakis
> At the present time, running sudo pip3 in Fedora is not safe.
> Pip shares its installation directory with dnf, can remove
> dnf-managed files and generally break the Python 3 interpreter.
This is true of every version of pip, not merely pip3. It was also
true of CPAN, and of many gradle, maven, and ant working environments
that semi-randomly collate the very latest versions of indeterminate
components and spray them on top of your system workspace with their
own quite distinct ideas about packaging and versioning.
There is no solution to this problem, except to use tools like
"pyvenv" to set aside secluded workspaces for Python modules and their
dependencies assembly. So, for most developers, they *should not* use
"sudo pip". They should remain in user space, or possibly in shared
workspaces, to avoid overwriting system components.
Nothing is changing in terms of *recommended* practices. This change
proposal is entirely about harm mitigation for the cases where users
*do* run "sudo pip ...", either because that's their instinctive
reaction to a permissions error, or because some misguided
installation instructions for a 3rd party package advised them to do
it.
Debian and derivatives already mitigate the potential harm for these
cases by requiring the "--install-layout=deb" option to be passed to
get distutils to install into the system directories rather than doing
it by default: https://wiki.debian.org/Python#Deviations_from_upstream
Their approach means that any harm caused by "sudo pip install X" can
subsequently be fully reversed by doing "sudo pip uninstall X".
At this moment, this is NOT true for Fedora and derivatives. Instead,
the remediation step here is "sudo pip uninstall X && sudo dnf
reinstall <something>" where you have to:
1. Figure out what "<something>" needs to be
2. Hope that whatever you broke didn't affect your ability to run
"sudo dnf reinstall"
> Our first attempt to make sudo pip safe on Fedora [0] was
> based on using a different binary (/usr/libexec/system-python)
> for RPM packaging purposes and changing the behavior
> of /usr/bin/python3 (and pip that uses its settings) to install
> under /usr/local by default. Switching all the Python 3 packages
Oh, Oh my. The extent to which this unworkable is... fascinating.
Nico, the contemptuous tone you have adopted in this post is entirely
inappropriate. Please give other list participants the courtesy of
assuming expertise at least equivalent to your own, rather than
engaging in attempted displays of assumed superiority.
You
will inevitably install incompatible future versions of critical
packages which are incompatible with the Fedora system packages. And
as soon as you install one that breaks RPM, if /usr/local/ if ahead of
/usr in your search path for modules, you are *screwed*.
This isn't true, as long as the fix is as simple as using pip to
uninstall whatever problematic package you just installed.
At the moment, that isn't the case on Fedora and derivatives, since
"sudo pip install ..." can actually *corrupt* a system package
installation, rather than merely shadowing it at import time the way
it does on Debian et al.
And if
/usr/local is first, well, an RPM update may introduce a component
that is incompatible with the pip installed modules at arbitrary
times.
The goal of this change isn't to allow co-existence of arbitrary
upstream and downstream versions as supported combinations - it's to
make sure that forced installation of an incompatible upstream version
is an easily reversible error, rather than a potentially
system-breaking mistake.
> We decided to try a different approach. The main idea is to
detect
> an ongoing RPM build and modify the behavior of the Python 3
> executable only when in normal user environment so that RPM builds
> won't be affected at all.
See https://xkcd.com/1172/ . You're inventing a workflow that isn't
supported by *anyone*.
The problem is that the default behaviour needs to change (to mitigate
the potential harm caused by a relatively common end user error), but
unlike Debian package builds (which know they need to set
"--install-layout=deb"), most RPM builds for Python packages currently
rely on that default behaviour as part of the build process. Changing
the default indiscriminately would thus be a breaking change that not
only affects Fedora RPM builds, but also COPR and other third party
RPM builds.
So we need a solution that retains the existing behaviour for RPM
builds, but changes the behaviour to be less potentially destructive
when run interactively at a shell prompt, or as part of a
configuration management script.
> The adjustment of the behavior can be done on different levels.
> The first option is to set the sys.prefix variable to /usr/local
> when the interpreter is initialized. This will affect
> all the install methods, but the solution can cause some
> problems in applications that rely on the value of sys.prefix.
> A prototype of this implementation can be seen here [1].
I'm sorry, but.... ouch. Please stop trying to implement "pip install"
as a system installation tool.
That is not the goal of the change.
The effort would be better spent
upgrading and enhancing "py2pack".
Improving the level of commonality and collaboration between Fedora &
Mageia's pyp2rpm and openSUSE's py2pack would indeed be desirable, but
it's entirely orthogonal to the harm mitigation exercise being
discussed here.
> The other possibility is to limit the pip install location
change
> to distutils and pip [2]. This is the "safer" option, but does
> not cover all corner cases. For example, Python software built
> locally using cmake or similar tools will be installed into
> /usr/lib and can conflict with system tools. Debian chose to
> implement similar solution.
It's local environment specific, unstable software sensitive to
arbitrary and unmanaged upstream dependency updates, and extremely
sensitive to local system pip modules. It *does not belong* in
/usr/lib. Because the components are modular and bundled in a non-RPM
compatible fashion, it behooves developers to use a tool to segregate
the tools as much as feasible from the Fedora underlying
infrastructure. i.e., use pyvenv to build them in a contained
environment segregated from the system files.
Helping users that are already doing the right thing isn't the problem
at hand - this is about making it easier for users to recover from
doing the *wrong* thing.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
4:34 a.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
If the "only" reason to change the current behavior is to prevent
users from nuking their systems (be it by accident, or by following
outdated instructions from the web), then why not prevent running
"sudo pip" at all?
Adding a small patch to pip to print an explanatory message ("This is
unsafe, make sure you know what you're doing" or something like that,
maybe even mentioning virtualenv usage) and abort when run as root
would be a very simple solution, IMO (just a few LOC of python) ...
this could then even be overridden by an env variable, for example
"IKNOWWHATIMDOING=1 sudo pip install X" for people who absolutely need
it.
This also seems far less invasive than the other proposed changes, and
should be possible for both python2 and python3.
Just my 2c.
Fabio
On Thu, Apr 27, 2017 at 8:32 AM, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
> On 27 April 2017 at 11:47, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
>> On Wed, Apr 26, 2017 at 7:13 AM, Charalampos Stratakis
>>> At the present time, running sudo pip3 in Fedora is not safe.
>>> Pip shares its installation directory with dnf, can remove
>>> dnf-managed files and generally break the Python 3 interpreter.
>>
>> This is true of every version of pip, not merely pip3. It was also
>> true of CPAN, and of many gradle, maven, and ant working environments
>> that semi-randomly collate the very latest versions of indeterminate
>> components and spray them on top of your system workspace with their
>> own quite distinct ideas about packaging and versioning.
>>
>> There is no solution to this problem, except to use tools like
>> "pyvenv" to set aside secluded workspaces for Python modules and their
>> dependencies assembly. So, for most developers, they *should not* use
>> "sudo pip". They should remain in user space, or possibly in shared
>> workspaces, to avoid overwriting system components.
>
> Nothing is changing in terms of *recommended* practices. This change
> proposal is entirely about harm mitigation for the cases where users
> *do* run "sudo pip ...", either because that's their instinctive
> reaction to a permissions error, or because some misguided
> installation instructions for a 3rd party package advised them to do
> it.
>
> Debian and derivatives already mitigate the potential harm for these
> cases by requiring the "--install-layout=deb" option to be passed to
> get distutils to install into the system directories rather than doing
> it by default: https://wiki.debian.org/Python#Deviations_from_upstream
>
> Their approach means that any harm caused by "sudo pip install X" can
> subsequently be fully reversed by doing "sudo pip uninstall X".
>
> At this moment, this is NOT true for Fedora and derivatives. Instead,
> the remediation step here is "sudo pip uninstall X && sudo dnf
> reinstall <something>" where you have to:
>
> 1. Figure out what "<something>" needs to be
> 2. Hope that whatever you broke didn't affect your ability to run
> "sudo dnf reinstall"
>
>>> Our first attempt to make sudo pip safe on Fedora [0] was
>>> based on using a different binary (/usr/libexec/system-python)
>>> for RPM packaging purposes and changing the behavior
>>> of /usr/bin/python3 (and pip that uses its settings) to install
>>> under /usr/local by default. Switching all the Python 3 packages
>>
>> Oh, Oh my. The extent to which this unworkable is... fascinating.
>
> Nico, the contemptuous tone you have adopted in this post is entirely
> inappropriate. Please give other list participants the courtesy of
> assuming expertise at least equivalent to your own, rather than
> engaging in attempted displays of assumed superiority.
>
>> You
>> will inevitably install incompatible future versions of critical
>> packages which are incompatible with the Fedora system packages. And
>> as soon as you install one that breaks RPM, if /usr/local/ if ahead of
>> /usr in your search path for modules, you are *screwed*.
>
> This isn't true, as long as the fix is as simple as using pip to
> uninstall whatever problematic package you just installed.
>
> At the moment, that isn't the case on Fedora and derivatives, since
> "sudo pip install ..." can actually *corrupt* a system package
> installation, rather than merely shadowing it at import time the way
> it does on Debian et al.
>
>> And if
>> /usr/local is first, well, an RPM update may introduce a component
>> that is incompatible with the pip installed modules at arbitrary
>> times.
>
> The goal of this change isn't to allow co-existence of arbitrary
> upstream and downstream versions as supported combinations - it's to
> make sure that forced installation of an incompatible upstream version
> is an easily reversible error, rather than a potentially
> system-breaking mistake.
>
>>> We decided to try a different approach. The main idea is to detect
>>> an ongoing RPM build and modify the behavior of the Python 3
>>> executable only when in normal user environment so that RPM builds
>>> won't be affected at all.
>>
>> See https://xkcd.com/1172/ . You're inventing a workflow that isn't
>> supported by *anyone*.
>
> The problem is that the default behaviour needs to change (to mitigate
> the potential harm caused by a relatively common end user error), but
> unlike Debian package builds (which know they need to set
> "--install-layout=deb"), most RPM builds for Python packages currently
> rely on that default behaviour as part of the build process. Changing
> the default indiscriminately would thus be a breaking change that not
> only affects Fedora RPM builds, but also COPR and other third party
> RPM builds.
>
> So we need a solution that retains the existing behaviour for RPM
> builds, but changes the behaviour to be less potentially destructive
> when run interactively at a shell prompt, or as part of a
> configuration management script.
>
>>> The adjustment of the behavior can be done on different levels.
>>> The first option is to set the sys.prefix variable to /usr/local
>>> when the interpreter is initialized. This will affect
>>> all the install methods, but the solution can cause some
>>> problems in applications that rely on the value of sys.prefix.
>>> A prototype of this implementation can be seen here [1].
>>
>> I'm sorry, but.... ouch. Please stop trying to implement "pip
install"
>> as a system installation tool.
>
> That is not the goal of the change.
>
>> The effort would be better spent
>> upgrading and enhancing "py2pack".
>
> Improving the level of commonality and collaboration between Fedora &
> Mageia's pyp2rpm and openSUSE's py2pack would indeed be desirable, but
> it's entirely orthogonal to the harm mitigation exercise being
> discussed here.
>
>>> The other possibility is to limit the pip install location change
>>> to distutils and pip [2]. This is the "safer" option, but does
>>> not cover all corner cases. For example, Python software built
>>> locally using cmake or similar tools will be installed into
>>> /usr/lib and can conflict with system tools. Debian chose to
>>> implement similar solution.
>>
>> It's local environment specific, unstable software sensitive to
>> arbitrary and unmanaged upstream dependency updates, and extremely
>> sensitive to local system pip modules. It *does not belong* in
>> /usr/lib. Because the components are modular and bundled in a non-RPM
>> compatible fashion, it behooves developers to use a tool to segregate
>> the tools as much as feasible from the Fedora underlying
>> infrastructure. i.e., use pyvenv to build them in a contained
>> environment segregated from the system files.
>
> Helping users that are already doing the right thing isn't the problem
> at hand - this is about making it easier for users to recover from
> doing the *wrong* thing.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
7:40 a.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On 27 April 2017 at 19:34, Fabio Valentini <decathorpe(a)gmail.com> wrote:
If the "only" reason to change the current behavior is to
prevent
users from nuking their systems (be it by accident, or by following
outdated instructions from the web), then why not prevent running
"sudo pip" at all?
The main problem with that approach is that it breaks container build
processes where there's a far more constrained sequence of operations
than we see on a developer workstation or a traditional stateful
server:
- install a known set of system packages
- install a known set of Python packages into the system Python
- run a single known application directly in the system Python
The immutability of the container image then protects the app
developer from having to support arbitrary combinations - they only
support the specific combination that *they* put together.
It's still an unresolved design debate in the upstream Python
community as to whether this is a bad idea or not - some folks
advocate for always using virtual environments (even in single purpose
containers), while others see the Python level virtual environment as
being redundant when you already have the system level container
providing isolation from other processes.
So even though at the distro level we'd advise against doing that, I
don't think it makes sense for us to go out of our way to break it
when other options are available.
Longer term, the upstream pip devs *would* like to get to a design
closer to the npm one (where global installs are avoided by default
and you have to supply an "I really want a system global installation"
command line flag to override that), but they're not only up against
the same backwards compatibility constraints that we are in terms of
existing container and system package build processes, but also have
to provide sensible behaviour on non-Linux systems (see [1] for the
gory details).
Cheers,
Nick.
[1] https://github.com/pypa/pip/issues/1668
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
8:04 a.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On Thu, Apr 27, 2017 at 04:32:09PM +1000, Nick Coghlan wrote:
On 27 April 2017 at 11:47, Nico Kadel-Garcia <nkadel(a)gmail.com>
wrote:
> On Wed, Apr 26, 2017 at 7:13 AM, Charalampos Stratakis
>> At the present time, running sudo pip3 in Fedora is not safe.
>> Pip shares its installation directory with dnf, can remove
>> dnf-managed files and generally break the Python 3 interpreter.
>
> This is true of every version of pip, not merely pip3. It was also
> true of CPAN, and of many gradle, maven, and ant working environments
> that semi-randomly collate the very latest versions of indeterminate
> components and spray them on top of your system workspace with their
> own quite distinct ideas about packaging and versioning.
>
> There is no solution to this problem, except to use tools like
> "pyvenv" to set aside secluded workspaces for Python modules and their
> dependencies assembly. So, for most developers, they *should not* use
> "sudo pip". They should remain in user space, or possibly in shared
> workspaces, to avoid overwriting system components.
Nothing is changing in terms of *recommended* practices. This change
proposal is entirely about harm mitigation for the cases where users
*do* run "sudo pip ...", either because that's their instinctive
reaction to a permissions error, or because some misguided
installation instructions for a 3rd party package advised them to do
it.
FWIW, Openstack's devstack script will use "sudo pip" to install
python bits required by openstack and thus often splatter any RPM
managed versions of the same modules.
Debian and derivatives already mitigate the potential harm for these
cases by requiring the "--install-layout=deb" option to be passed to
get distutils to install into the system directories rather than doing
it by default: https://wiki.debian.org/Python#Deviations_from_upstream
Their approach means that any harm caused by "sudo pip install X" can
subsequently be fully reversed by doing "sudo pip uninstall X".
At this moment, this is NOT true for Fedora and derivatives. Instead,
the remediation step here is "sudo pip uninstall X && sudo dnf
reinstall <something>" where you have to:
1. Figure out what "<something>" needs to be
2. Hope that whatever you broke didn't affect your ability to run
"sudo dnf reinstall"
Yep, recovering the system python install to a pristine state after
'devstack' has done its stuff is very painful right now :-(
devstack was originally written for Ubuntu systems, so I guess they
don't suffer as much due to the Debian specific change you describe
above.
Which location takes priority in Debian if the same module is installed
in both places ? The DPKG location, or the Pip location ? Presumably it
would have to be the pip version that takes priority if you want it to
be usable for updating the (likely older) distro provided versions.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
8:48 a.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On 27 April 2017 at 23:04, Daniel P. Berrange <berrange(a)redhat.com> wrote:
On Thu, Apr 27, 2017 at 04:32:09PM +1000, Nick Coghlan wrote:
> Their approach means that any harm caused by "sudo pip install X" can
> subsequently be fully reversed by doing "sudo pip uninstall X".
>
> At this moment, this is NOT true for Fedora and derivatives. Instead,
> the remediation step here is "sudo pip uninstall X && sudo dnf
> reinstall <something>" where you have to:
>
> 1. Figure out what "<something>" needs to be
> 2. Hope that whatever you broke didn't affect your ability to run
> "sudo dnf reinstall"
Yep, recovering the system python install to a pristine state after
'devstack' has done its stuff is very painful right now :-(
devstack was originally written for Ubuntu systems, so I guess they
don't suffer as much due to the Debian specific change you describe
above.
Which location takes priority in Debian if the same module is installed
in both places ? The DPKG location, or the Pip location ? Presumably it
would have to be the pip version that takes priority if you want it to
be usable for updating the (likely older) distro provided versions.
Aye, /usr/local/lib has priority:
$ docker run --rm ncoghlan/debian-python python3 -m site
sys.path = [
'/',
'/usr/lib/python3.4',
'/usr/lib/python3.4/plat-x86_64-linux-gnu',
'/usr/lib/python3.4/lib-dynload',
'/usr/local/lib/python3.4/dist-packages',
'/usr/lib/python3/dist-packages',
]
USER_BASE: '/root/.local' (doesn't exist)
USER_SITE: '/root/.local/lib/python3.4/site-packages' (doesn't exist)
ENABLE_USER_SITE: True
User level package installs take priority over system level ones
(regardless of distro), so the current container build use case for
root level pip installations can typically be met equally well by
running as a non-root user inside the container and doing "pip install
--user ...". Unfortunately, as with the venv option, there are a *lot*
of container build scripts out there that don't do that :(
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
9:17 a.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On Thu, Apr 27, 2017 at 11:48:06PM +1000, Nick Coghlan wrote:
On 27 April 2017 at 23:04, Daniel P. Berrange
<berrange(a)redhat.com> wrote:
> On Thu, Apr 27, 2017 at 04:32:09PM +1000, Nick Coghlan wrote:
>> Their approach means that any harm caused by "sudo pip install X" can
>> subsequently be fully reversed by doing "sudo pip uninstall X".
>>
>> At this moment, this is NOT true for Fedora and derivatives. Instead,
>> the remediation step here is "sudo pip uninstall X && sudo dnf
>> reinstall <something>" where you have to:
>>
>> 1. Figure out what "<something>" needs to be
>> 2. Hope that whatever you broke didn't affect your ability to run
>> "sudo dnf reinstall"
>
> Yep, recovering the system python install to a pristine state after
> 'devstack' has done its stuff is very painful right now :-(
>
> devstack was originally written for Ubuntu systems, so I guess they
> don't suffer as much due to the Debian specific change you describe
> above.
>
> Which location takes priority in Debian if the same module is installed
> in both places ? The DPKG location, or the Pip location ? Presumably it
> would have to be the pip version that takes priority if you want it to
> be usable for updating the (likely older) distro provided versions.
Aye, /usr/local/lib has priority:
$ docker run --rm ncoghlan/debian-python python3 -m site
sys.path = [
'/',
'/usr/lib/python3.4',
'/usr/lib/python3.4/plat-x86_64-linux-gnu',
'/usr/lib/python3.4/lib-dynload',
'/usr/local/lib/python3.4/dist-packages',
'/usr/lib/python3/dist-packages',
]
USER_BASE: '/root/.local' (doesn't exist)
USER_SITE: '/root/.local/lib/python3.4/site-packages' (doesn't exist)
ENABLE_USER_SITE: True
User level package installs take priority over system level ones
(regardless of distro), so the current container build use case for
root level pip installations can typically be met equally well by
running as a non-root user inside the container and doing "pip install
--user ...". Unfortunately, as with the venv option, there are a *lot*
of container build scripts out there that don't do that :(
It would be nice if openstack devstack didn't install anything with
sudo and instead kept it all isolated as a user, but I don't see
such a change happening. So anything we can do to reduce the damage
of "sudo pip" is welcome, particularly if it aligns with what Debian
already do.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
9:07 a.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On 27 April 2017 at 02:32, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
On 27 April 2017 at 11:47, Nico Kadel-Garcia <nkadel(a)gmail.com>
wrote:
> On Wed, Apr 26, 2017 at 7:13 AM, Charalampos Stratakis
>> At the present time, running sudo pip3 in Fedora is not safe.
>> Pip shares its installation directory with dnf, can remove
>> dnf-managed files and generally break the Python 3 interpreter.
>
> This is true of every version of pip, not merely pip3. It was also
> true of CPAN, and of many gradle, maven, and ant working environments
> that semi-randomly collate the very latest versions of indeterminate
> components and spray them on top of your system workspace with their
> own quite distinct ideas about packaging and versioning.
>
> There is no solution to this problem, except to use tools like
> "pyvenv" to set aside secluded workspaces for Python modules and their
> dependencies assembly. So, for most developers, they *should not* use
> "sudo pip". They should remain in user space, or possibly in shared
> workspaces, to avoid overwriting system components.
Nothing is changing in terms of *recommended* practices. This change
proposal is entirely about harm mitigation for the cases where users
*do* run "sudo pip ...", either because that's their instinctive
reaction to a permissions error, or because some misguided
installation instructions for a 3rd party package advised them to do
it.
Debian and derivatives already mitigate the potential harm for these
cases by requiring the "--install-layout=deb" option to be passed to
get distutils to install into the system directories rather than doing
it by default: https://wiki.debian.org/Python#Deviations_from_upstream
Their approach means that any harm caused by "sudo pip install X" can
subsequently be fully reversed by doing "sudo pip uninstall X".
At this moment, this is NOT true for Fedora and derivatives. Instead,
the remediation step here is "sudo pip uninstall X && sudo dnf
reinstall <something>" where you have to:
1. Figure out what "<something>" needs to be
2. Hope that whatever you broke didn't affect your ability to run
"sudo dnf reinstall"
I have a question. If there is a working version of what we want, is
there a reason we should not adopt that version with appropriate
hacks? Would this give any future PEP some groundswell of approval?
--
Stephen J Smoogen.
9:28 a.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On 28 April 2017 at 00:07, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On 27 April 2017 at 02:32, Nick Coghlan <ncoghlan(a)gmail.com>
wrote:
> At this moment, this is NOT true for Fedora and derivatives. Instead,
> the remediation step here is "sudo pip uninstall X && sudo dnf
> reinstall <something>" where you have to:
>
> 1. Figure out what "<something>" needs to be
> 2. Hope that whatever you broke didn't affect your ability to run
> "sudo dnf reinstall"
I have a question. If there is a working version of what we want, is
there a reason we should not adopt that version with appropriate
hacks?
Only the fact that even what Debian have is still pretty flawed, so it
made sense to try and see if we could think of a potentially better
alternative.
That said, the gist of my reply to the original Python SIG thread was
that I think we've reached the end of that process, and it's time to
just adopt an approach that's mostly consistent with Debian's approach
(plus any necessary adjustments to avoid breaking the world for RPM
builds)
Would this give any future PEP some groundswell of approval?
I think so - once the Debian/Ubuntu and Fedora/RHEL/CentOS ecosystems
share a common way of doing things at the distro level, it's often
easier to make the case for changes upstream as "general Linux
integration improvements", which sidesteps arguments against
maintaining "distro-specific workarounds" in upstream tools.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
11:26 a.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On Fri, 28 Apr 2017, Nick Coghlan wrote:
On 28 April 2017 at 00:07, Stephen John Smoogen
<smooge(a)gmail.com> wrote:
> Would this give any future PEP some groundswell of approval?
I think so - once the Debian/Ubuntu and Fedora/RHEL/CentOS ecosystems
share a common way of doing things at the distro level, it's often
easier to make the case for changes upstream as "general Linux
integration improvements", which sidesteps arguments against
maintaining "distro-specific workarounds" in upstream tools.
For what it's worth, Solaris 11 puts OS-packaged Python modules in, e.g.,
/usr/lib/python2.7/vendor-packages, leaving /usr/lib/python2.7/site-packages for pip.
Another variation on the same theme. Their OS package manager is written in Python, too.
https://hg.java.net/hg/solaris-userland~gate/file/d240e0693286/make-rules...
https://hg.java.net/hg/solaris-userland~gate/file/d240e0693286/components...
--
Peter Oliver
6:59 p.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On Thu, Apr 27, 2017 at 2:32 AM, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
On 27 April 2017 at 11:47, Nico Kadel-Garcia <nkadel(a)gmail.com>
wrote:
> On Wed, Apr 26, 2017 at 7:13 AM, Charalampos Stratakis
>> At the present time, running sudo pip3 in Fedora is not safe.
>> Pip shares its installation directory with dnf, can remove
>> dnf-managed files and generally break the Python 3 interpreter.
>
> This is true of every version of pip, not merely pip3. It was also
> true of CPAN, and of many gradle, maven, and ant working environments
> that semi-randomly collate the very latest versions of indeterminate
> components and spray them on top of your system workspace with their
> own quite distinct ideas about packaging and versioning.
>
> There is no solution to this problem, except to use tools like
> "pyvenv" to set aside secluded workspaces for Python modules and their
> dependencies assembly. So, for most developers, they *should not* use
> "sudo pip". They should remain in user space, or possibly in shared
> workspaces, to avoid overwriting system components.
Nothing is changing in terms of *recommended* practices. This change
proposal is entirely about harm mitigation for the cases where users
*do* run "sudo pip ...", either because that's their instinctive
reaction to a permissions error, or because some misguided
installation instructions for a 3rd party package advised them to do
it.
Debian and derivatives already mitigate the potential harm for these
cases by requiring the "--install-layout=deb" option to be passed to
get distutils to install into the system directories rather than doing
it by default: https://wiki.debian.org/Python#Deviations_from_upstream
Their approach means that any harm caused by "sudo pip install X" can
subsequently be fully reversed by doing "sudo pip uninstall X".
At this moment, this is NOT true for Fedora and derivatives. Instead,
the remediation step here is "sudo pip uninstall X && sudo dnf
reinstall <something>" where you have to:
1. Figure out what "<something>" needs to be
2. Hope that whatever you broke didn't affect your ability to run
"sudo dnf reinstall"
>> Our first attempt to make sudo pip safe on Fedora [0] was
>> based on using a different binary (/usr/libexec/system-python)
>> for RPM packaging purposes and changing the behavior
>> of /usr/bin/python3 (and pip that uses its settings) to install
>> under /usr/local by default. Switching all the Python 3 packages
>
> Oh, Oh my. The extent to which this unworkable is... fascinating.
Nico, the contemptuous tone you have adopted in this post is entirely
inappropriate. Please give other list participants the courtesy of
assuming expertise at least equivalent to your own, rather than
engaging in attempted displays of assumed superiority.
I'll try to scale back. But it's a very familiar issue. It's
difficult, even impossible, to completely isolate the results of one
package management from the other without completely segregating their
work spaces. It's been tried with CPAN, ant, gradle, maven, and other
build systems.
I actually tried similar approaches to isolate pip insalles for
airflow, and for awscli. It was very painful. The dependencies
themselves dependencies, including 3 distinct versions of the "Sphinx"
document processing system, one version of which broke compilation for
other components because the current version was incompatible with
older software on the system, none of which were reasonable to go back
and introduce locked software versions for. And the problem is a
frequent one. Pip published modules are neither required, nor
particularly expected, to remain compatible with older versions of
software which may be dependent on it.
And yes, I'd had "pip install" break RPM by upgrading its modules. It
even breaks other tools that are already working, even pip installed
tools, because of the tendency to upgrade to the latest version of
every component.
It's possible to package Python modules consistently. "py2pack" has
proven an invaluable tool for me to actually package Python modules as
RPM's for system deployment, and I do recommend it for general use.
"pyvenv" can and does effectively isolate pip install from the base
Fedora system for the safety of the base Fedora and of the particular
pip environment.
> You
> will inevitably install incompatible future versions of critical
> packages which are incompatible with the Fedora system packages. And
> as soon as you install one that breaks RPM, if /usr/local/ if ahead of
> /usr in your search path for modules, you are *screwed*.
This isn't true, as long as the fix is as simple as using pip to
uninstall whatever problematic package you just installed.
At the moment, that isn't the case on Fedora and derivatives, since
"sudo pip install ..." can actually *corrupt* a system package
installation, rather than merely shadowing it at import time the way
it does on Debian et al.
It's not merely that it can corrupt a system package, which it can do.
It can introduce dependencies which replace functionality for tested
system versions of those packages. Such an approach leaving the
locally installed version of a module as the system default can
actually *break pip", and even brak RPM, or cause flapping of version
and successful functionality for the desired user application as the
pip module and a later installed RPM version, fight it out out for
version supremacy.
Been there, done that, had to yank out the modules manually and take
back sudo access from the developer who kept using "sudo pip install"
on a shared system. That developer was also confident that pip did
something like version control. It's not normally configured to do so:
dependencies are usually published with no version stated. When a
version is stated, it's usually a ">=" version number, and is
generally not set to lock down the current version of modules that may
have major and incompatible API changes.
> And if
> /usr/local is first, well, an RPM update may introduce a component
> that is incompatible with the pip installed modules at arbitrary
> times.
The goal of this change isn't to allow co-existence of arbitrary
upstream and downstream versions as supported combinations - it's to
make sure that forced installation of an incompatible upstream version
is an easily reversible error, rather than a potentially
system-breaking mistake.
I'm on board with the goal. I just think it's much safer to segregate
them further from system utilities. pyvenv does a reasonably good job,
and is much less likely to attempt to install an inappropriately
upgraded system module in the default Python module paths, breaking
other critical system tools.
>> We decided to try a different approach. The main idea is to
detect
>> an ongoing RPM build and modify the behavior of the Python 3
>> executable only when in normal user environment so that RPM builds
>> won't be affected at all.
>
> See https://xkcd.com/1172/ . You're inventing a workflow that isn't
> supported by *anyone*.
The problem is that the default behaviour needs to change (to mitigate
the potential harm caused by a relatively common end user error), but
unlike Debian package builds (which know they need to set
"--install-layout=deb"), most RPM builds for Python packages currently
rely on that default behaviour as part of the build process. Changing
the default indiscriminately would thus be a breaking change that not
only affects Fedora RPM builds, but also COPR and other third party
RPM builds.
So we need a solution that retains the existing behaviour for RPM
builds, but changes the behaviour to be less potentially destructive
when run interactively at a shell prompt, or as part of a
configuration management script.
I'd call the approach you describe less *likely* destructive. Not less
potentially destructive. Since "sudo pip install" can, through no
malice of anyone involved, install packages that have never been
tested together, run their "build" procedures, and do an accidental
"rm -rf" of your entire filesystem with just such a component, the
potential for destruction remains as high as it is for any software
run as the root user.
>> The adjustment of the behavior can be done on different
levels.
>> The first option is to set the sys.prefix variable to /usr/local
>> when the interpreter is initialized. This will affect
>> all the install methods, but the solution can cause some
>> problems in applications that rely on the value of sys.prefix.
>> A prototype of this implementation can be seen here [1].
>
> I'm sorry, but.... ouch. Please stop trying to implement "pip install"
> as a system installation tool.
That is not the goal of the change.
If you're putting the modules in /usr/local/, for default use by all
system users, then it looks very much like a system installation tool
> The effort would be better spent
> upgrading and enhancing "py2pack".
Improving the level of commonality and collaboration between Fedora &
Mageia's pyp2rpm and openSUSE's py2pack would indeed be desirable, but
it's entirely orthogonal to the harm mitigation exercise being
discussed here.
Allow me to respectfully. Easing the path to getting the modules into
RPM would profoundly improve compatibility, and package dependency
testing and control, far more than investing the effort into working
around the compatibility issues and risks of a "sudo pip install"
operations. Moreover, it would help provide extremely valuable version
control of the build and install time dependencies of the desired pip
module.
>> The other possibility is to limit the pip install location
change
>> to distutils and pip [2]. This is the "safer" option, but does
>> not cover all corner cases. For example, Python software built
>> locally using cmake or similar tools will be installed into
>> /usr/lib and can conflict with system tools. Debian chose to
>> implement similar solution.
>
> It's local environment specific, unstable software sensitive to
> arbitrary and unmanaged upstream dependency updates, and extremely
> sensitive to local system pip modules. It *does not belong* in
> /usr/lib. Because the components are modular and bundled in a non-RPM
> compatible fashion, it behooves developers to use a tool to segregate
> the tools as much as feasible from the Fedora underlying
> infrastructure. i.e., use pyvenv to build them in a contained
> environment segregated from the system files.
Helping users that are already doing the right thing isn't the problem
at hand - this is about making it easier for users to recover from
doing the *wrong* thing.
Cheers,
Nick.
Wouldn't it be more effective, more safe, and more efficient to
improve the existing support for doing "the right thing", rather than
trying to outsmart a build and deployment system that is essentially
outside your control? To encourage the use of "pyvenv" for local such
modules, in a local userspace, rather than as a default system
version?
Frankly, I've learned a very real distrust for "pip install". It's not
a loathing for their attempt to create such a system. It's hard won
experience from the last 5 or so such systems I've had to deal with
personally and professionally. Version control and component
compatibility have repeatedly bitten me *very* hard, especially when a
component upgrade breaks other previously stable components. And
debugging them can be *nightmarish*.
9:30 p.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On 1 May 2017 at 09:59, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
Wouldn't it be more effective, more safe, and more efficient to
improve the existing support for doing "the right thing", rather than
trying to outsmart a build and deployment system that is essentially
outside your control? To encourage the use of "pyvenv" for local such
modules, in a local userspace, rather than as a default system
version?
This is already happening, and is entirely independent of the
discussion at hand (e.g. see [1], a presentation I did with Graham
Dumpleton at Red Hat Summit/DevNation last year advocating for Red
Hat's customers to adopt exactly this model). On Fedora's Developer
Portal, virtual environments share the front page of the Python
section with running Python itself:
https://developer.fedoraproject.org/tech/languages/python/python-installa...
Responding to "We want to make running 'sudo pip install' less harmful
and easier to recover from when people do it by mistake" with "We
should discourage the use of 'sudo pip install'" remains an
unproductive non sequitur - we *know* it's inherently fragile, and
requires deep knowledge of both Python packaging and RPM packaging to
do reliably. However, Red Hat can't (and won't) answer a commercial
support call from a distressed customer with "Ooh, you shouldn't have
done that - sucks to be you" (although these supportability problems
*are* one of the reasons we only ship "pip" commercially through
Software Collections, and not as part of the system Python runtime).
Fortunately, we have the ability to influence *all* of the moving
parts (upstream pip, upstream CPython, downstream distros) here, and
help to incrementally adjust their respective default behaviours so
that the key risks involved in running "sudo pip install" are
comparable to those involved in running "curl $REMOTE_SCRIPT | sudo
sh".
If the intended benefit of this change remains unclear, it may help to
focus on a specific concrete case, which would be that the following
operations should be completely indistinguishable at the system level
from not having done anything at all (except in the sudo logs):
$ sudo pip3 install contextlib2
$ sudo pip3 uninstall contextlib2
At the moment, that's *not* the case if you had previously done "sudo
dnf install python3-contextlib2", as both of the above commands will
mess with the system contextlib2 packages. With the proposed changes,
contextlib2 may behave unexpectedly while the non-system version is
installed, but removing the pip installed version will be sufficient
to restore the affected machine to its previous state. (I chose
contextlib2 as the example here, rather than something more complex
like ansible, as pip installing components with dependencies makes the
cleanup process more complicated. However, the /usr/local/ split helps
there as well, by making the installed-via-pip versions easier to
identify even without checking the PEP 376 installation metadata)
Cheers,
Nick.
[1]
https://www.slideshare.net/ncoghlan_dev/developing-in-python-on-red-hat-p...
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
7:47 a.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On Sun, Apr 30, 2017 at 10:30 PM, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
On 1 May 2017 at 09:59, Nico Kadel-Garcia <nkadel(a)gmail.com>
wrote:
> Wouldn't it be more effective, more safe, and more efficient to
> improve the existing support for doing "the right thing", rather than
> trying to outsmart a build and deployment system that is essentially
> outside your control? To encourage the use of "pyvenv" for local such
> modules, in a local userspace, rather than as a default system
> version?
This is already happening, and is entirely independent of the
discussion at hand (e.g. see [1], a presentation I did with Graham
Dumpleton at Red Hat Summit/DevNation last year advocating for Red
Hat's customers to adopt exactly this model). On Fedora's Developer
Portal, virtual environments share the front page of the Python
section with running Python itself:
https://developer.fedoraproject.org/tech/languages/python/python-installa...
Good that the conversation is happening.
Responding to "We want to make running 'sudo pip
install' less harmful
and easier to recover from when people do it by mistake" with "We
should discourage the use of 'sudo pip install'" remains an
unproductive non sequitur - we *know* it's inherently fragile, and
requires deep knowledge of both Python packaging and RPM packaging to
do reliably. However, Red Hat can't (and won't) answer a commercial
support call from a distressed customer with "Ooh, you shouldn't have
done that - sucks to be you" (although these supportability problems
*are* one of the reasons we only ship "pip" commercially through
Software Collections, and not as part of the system Python runtime).
This seems wise. Good guidelines for safer practices would be invaluable.
Fortunately, we have the ability to influence *all* of the moving
parts (upstream pip, upstream CPython, downstream distros) here, and
help to incrementally adjust their respective default behaviours so
that the key risks involved in running "sudo pip install" are
comparable to those involved in running "curl $REMOTE_SCRIPT | sudo
sh".
If only. The difficulty is the dependencies. The behavior is very
difficult to predict, and dangerously inconsistent, if the
dependencies happen to be already installed via RPM or already
installed via even other "sudo pip install" operations. It's a
fundamental risk of all the "build me on the fly" installers,
historically including CPAN, ant, maven, gradle, and is currently
playing out with "pip install".
If the intended benefit of this change remains unclear, it may help
to
focus on a specific concrete case, which would be that the following
operations should be completely indistinguishable at the system level
from not having done anything at all (except in the sudo logs):
$ sudo pip3 install contextlib2
$ sudo pip3 uninstall contextlib2
And this successfully ignores *all* the dependencies which contextlib2
may add at installation time. An archetype for this right now is the
"awscli" module, whose dependencies themselves require dependencies
that require incompatible versions of "Sphinx" to generate their
documentation. (Been there, done that, recently.)
It also ignores this timeline:
* sudo pip3 install contextlib2 # installs contextlib2 from 2017-05-01
* sudo pip3 install [module with more recent contextlib2 requirement
from 2017-05-02]
* sudo pip3 uninstall contextlib2
Which contextlib2 are you going to uninstall? It will typically
uninstall the more recent one from 2017-05-02, and the module with the
dependency. But the module from 2017-05-01 remains untouched.. And
yes, I've seen this happen with complex package dependencies.
At the moment, that's *not* the case if you had previously done
"sudo
dnf install python3-contextlib2", as both of the above commands will
mess with the system contextlib2 packages. With the proposed changes,
contextlib2 may behave unexpectedly while the non-system version is
installed, but removing the pip installed version will be sufficient
to restore the affected machine to its previous state. (I chose
contextlib2 as the example here, rather than something more complex
like ansible, as pip installing components with dependencies makes the
cleanup process more complicated. However, the /usr/local/ split helps
Yup. This is one of the big problems of the whole scheme. What might
be safe with one of the cleaner, more independent modules becomes
quite hazardous for something larger and more complex, such as "pip"
itself.
there as well, by making the installed-via-pip versions easier to
identify even without checking the PEP 376 installation metadata)
At a first glance, in theory, yes. But by installing it in a default
enabled location, I'm trying to point out that it puts other system
modules at risk of incompatible upgrades, particularly from
dependencies of dependencies that "sudo pip install" will activate
automatically. And worse: some modules actually actually provide
binaries with the same name, such as the "aws" and "awscli" modules,
which both install /usr/bin/aws. The result is "flapping". You get
whichever module was installed or upgraded last. "pip install" doesn't
provide enough control to prevent this: And it doesn't even report, in
advance, which modules are going to be installed or upgraded and
provide the option to continue.
What Red Hat did with the "software collections library" has, in my
hands-on experience, proven much safer as a working
non-default-enabled location for add-on modules. Encourage a working
RPM structure, and keep these local, manually installed components out
of /usr/lib, *and* out of /usr/local/lib default access, has been much
safer in my own work. Put it over in /opt/python2 or "/opt/pythn33" or
a similar, segregated location to be activated on an "as-needed"
basis, or encourage the use of pyvenv to keep it segregated.
> Cheers,
> Nick.
>
> [1]
https://www.slideshare.net/ncoghlan_dev/developing-in-python-on-red-hat-p...
>
> --
> Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
8:14 a.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On 1 May 2017 at 22:47, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Sun, Apr 30, 2017 at 10:30 PM, Nick Coghlan
<ncoghlan(a)gmail.com> wrote:
> If the intended benefit of this change remains unclear, it may help to
> focus on a specific concrete case, which would be that the following
> operations should be completely indistinguishable at the system level
> from not having done anything at all (except in the sudo logs):
>
> $ sudo pip3 install contextlib2
> $ sudo pip3 uninstall contextlib2
And this successfully ignores *all* the dependencies which contextlib2
may add at installation time.
There's a reason I chose contextlib2 as my example rather than
something more complex like ansible - I'm the maintainer of
contextlib2, and I know it doesn't have any runtime dependencies (and
likely never will, since it's a stdlib module backport).
Given the proposal at hand though, writing a
`remove-pip-installed-modules` cleaner utility becomes a lot simpler
that it is today, since it just needs to clear out any Python packages
it finds in /usr/local (based on the Python level installation
records), rather than needing to interact with the RPM database,
figure out which system packages may have potentially been corrupted
and reinstall them.
If the proposal is adjusted to also affect other installation
directories (like the one for scripts), it will also have the
significant benefit that any pip installed binaries will go into
`/usr/local/bin`, so they'll appear on the default path for all
regular users, but *won't* appear on the default path for "root".
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
6:36 p.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On Mon, May 1, 2017 at 9:14 AM, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
On 1 May 2017 at 22:47, Nico Kadel-Garcia <nkadel(a)gmail.com>
wrote:
> On Sun, Apr 30, 2017 at 10:30 PM, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
>> If the intended benefit of this change remains unclear, it may help to
>> focus on a specific concrete case, which would be that the following
>> operations should be completely indistinguishable at the system level
>> from not having done anything at all (except in the sudo logs):
>>
>> $ sudo pip3 install contextlib2
>> $ sudo pip3 uninstall contextlib2
>
> And this successfully ignores *all* the dependencies which contextlib2
> may add at installation time.
There's a reason I chose contextlib2 as my example rather than
something more complex like ansible - I'm the maintainer of
contextlib2, and I know it doesn't have any runtime dependencies (and
likely never will, since it's a stdlib module backport).
Heh: it seems as if you are cheating somewhat by choosing one of the
easiest components. I'm concerned that casual use of a new "pip3
install" localized utility will replicate the problems I described
fairly quickly, and in ways that someone not as experienced with
dependency violations will have difficulty cleaning up. I'm
particularly thinking of "awscli" and the various Sphinx version
dependencies of its dependency tree.
Given the proposal at hand though, writing a
`remove-pip-installed-modules` cleaner utility becomes a lot simpler
that it is today, since it just needs to clear out any Python packages
it finds in /usr/local (based on the Python level installation
records), rather than needing to interact with the RPM database,
figure out which system packages may have potentially been corrupted
and reinstall them.
That makes sense, at least to me. I continue to urge you to keep it
*out* of the default compiled in equivalents of PYTHONPATH. Perhaps
there needs to be something like a "pip3.local", to activate such such
modules in a better segregated space? One that attempts to set "bind
If the proposal is adjusted to also affect other installation
directories (like the one for scripts), it will also have the
significant benefit that any pip installed binaries will go into
`/usr/local/bin`, so they'll appear on the default path for all
regular users, but *won't* appear on the default path for "root".
I do see your point. I remain concerned about system utilities like
"rpm", which could wind up behaving rather differently for non-root
users and for root users due to using different sets of modules by
default for non-root users. And as desirable as enforcing careful
"bin" directory management, I think it would require enforcing an RPM
style packaging wrapper to prevent Python module installers from
ignoring common "pip --install" directives, and installing in
arbitrary hardcoded locations. I do remember encountering a few such
modules in the last few years, I don't know if the Pytnon developer
community has gotten better about that. I do hope so.
The idea of providing localized segregation of pip installations is
not unreasonable. I just don't think you can make it work safely by
integrating it into "sudo pip3 install". Would it be simpler to
provide a lightweight wrapper, a "pip3.local" script to set these
alternative locations? Maybe even better, replace "/usr/bin/pip3" with
the wrapper, and set the original raw "pip3" aside as
"/usr/bin/pip3.bin" for operation inside the wrapper? This is an old
and fairly stable stunt, used for "/usr/bin/mock" and
"/usr/bin/consolehelp" to segregate the ordinarey non-root user binary
from the more complex, compiled tool.
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
8:43 p.m.
New subject: What is your opinion on "sudo pip" fix for Fedora 27?
On 2 May 2017 at 09:36, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Mon, May 1, 2017 at 9:14 AM, Nick Coghlan
<ncoghlan(a)gmail.com> wrote:
> On 1 May 2017 at 22:47, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
>> On Sun, Apr 30, 2017 at 10:30 PM, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
>>> If the intended benefit of this change remains unclear, it may help to
>>> focus on a specific concrete case, which would be that the following
>>> operations should be completely indistinguishable at the system level
>>> from not having done anything at all (except in the sudo logs):
>>>
>>> $ sudo pip3 install contextlib2
>>> $ sudo pip3 uninstall contextlib2
>>
>> And this successfully ignores *all* the dependencies which contextlib2
>> may add at installation time.
>
> There's a reason I chose contextlib2 as my example rather than
> something more complex like ansible - I'm the maintainer of
> contextlib2, and I know it doesn't have any runtime dependencies (and
> likely never will, since it's a stdlib module backport).
Heh: it seems as if you are cheating somewhat by choosing one of the
easiest components. I'm concerned that casual use of a new "pip3
install" localized utility will replicate the problems I described
fairly quickly, and in ways that someone not as experienced with
dependency violations will have difficulty cleaning up. I'm
particularly thinking of "awscli" and the various Sphinx version
dependencies of its dependency tree.
Nico, this suggests you're still missing the essential point of the proposal.
Status quo: people run "sudo pip3 install <whatever>" and *corrupt
their system (or SCL) packages*. Remediation in the case of system
breakage will be some form of clearing out the pip installed
components, and reinstalling the dnf/yum managed ones.
Proposed change: people run "sudo pip3 install <whatever>" and only
`/usr/local` (or the equivalent `/opt/...` directory for SCLs) gets
modified. This will often "just work" (when there's no conflict with
system packages), and even when it doesn't, remediation only involves
removing the pip installed packages - the dnf/yum managed ones should
still be in their original pristine state.
Saying "This only mitigates the potential problems, it doesn't
completely eliminate them" doesn't make sense as a response to a harm
mitigation measure.
That said, I re-read the original change proposal page, and that
*does* give the impression that it completely solves the problem
(since even the title uses words like "safe" rather than the more
measured "safer"), so I've suggested on the Python SIG list that it be
reworded to better explain the scope and potential benefits.
> Given the proposal at hand though, writing a
> `remove-pip-installed-modules` cleaner utility becomes a lot simpler
> that it is today, since it just needs to clear out any Python packages
> it finds in /usr/local (based on the Python level installation
> records), rather than needing to interact with the RPM database,
> figure out which system packages may have potentially been corrupted
> and reinstall them.
That makes sense, at least to me. I continue to urge you to keep it
*out* of the default compiled in equivalents of PYTHONPATH. Perhaps
there needs to be something like a "pip3.local", to activate such such
modules in a better segregated space?
That's what per-user and venv installs are for, as well as SCLs and
containers at the OS level.
One thing I would like to start doing is more strongly encouraging the
use of `pipsi` ("pip script installer") when installing things like
awscli directly from PyPI for personal or system wide use, since that
automatically takes care of creating an application specific virtual
environment for the tool's dependencies.
However, there are still some issues with that around availability
(pipsi isn't in the Python SCLs or EPEL at this point), as well as
around readily upgrading components in the per-application venvs.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
2544
days inactive
2550
days old
18 comments
8 participants
participants (8)
-
Charalampos Stratakis -
Colin Walters -
Daniel P. Berrange -
Fabio Valentini -
Nick Coghlan -
Nico Kadel-Garcia -
Peter Oliver -
Stephen John Smoogen