----- Original Message ----- From: "Richard Ryniker" <ryniker@xxxxxxxxxxxx> To: devel-announce@xxxxxxxxxxxxxxxxxxxxxxx Cc: devel@xxxxxxxxxxxxxxxxxxxxxxx Sent: Friday, January 20, 2017 5:23:43 PM Subject: Re: F26 Self Contained Change: Making sudo pip Safe (Again) >> System-python makes sense: a Python environment dedicated to system >> activities which changes only in a controlled way (updates can be >> tested against a suite of system activities before they are applied; >> new Python releases and maintenance may be deferred indefinitely >> unless they contain required function or fix a relevant problem.) >> The activity of pip3 is a separate question, and the proposed change >> does not discuss complications this may introduce. Instead of a >> change to Fedora's Python semantics, which may confuse users and >> incurs continuing maintenance cost, would it not be better to convince >> Python's upstream developers to address this issue for all Python >> users and platforms? It would. However, the problem doesn't affect Windows or Mac, and Debian/Ubuntu already solve this at the distro level. There's not much motivation for upstream to address the issue quickly. >> If the wider community of Python users does not consider the value of >> this enhancement to module search semantics worth its cost, instead of >> Fedora-only changes to Python, perhaps Fedora could use Python's native >> mechanisms (such as pip3) in its Python packages. >> I already have an embarrassment of Python riches on my system - Python >> 2.7 and 3.5 from Fedora repositories, 3.6 from my local build, and >> probably another 3.6 from Fedora in the near future. The thought of >> doubling the number of locations where modules might be installed >> is... unsettling. Integrating dnf and pip3 more closely, so that packages installed by one could be uninstalled/upgraded with the other, would certainly be an interesting project. However, it would also be a very big project. It's not feasible to do in any reasonable time. >> I have a few Python applications that change sys.path, and suppose >> many others do. All of these have some potential to be confused by >> the proposed Fedora change; most likely they ignore it, and thereby >> can induce import failures. Can you be more specific? Do you have applications that hardcode Fedora's module path (which would break), or just ones that add additional entries to the existing path (which would not break)? Or are they doing something else? >> Even if Fedora "fixes" pip3, this cures only the most common >> conflicts. This may be good to do, but users with non-standard >> installation procedures still may interfere with dnf-managed files. If users have installation procedures that may interfere with dnf-managed files, they are doing it wrong. This change is about not providing a convenient tool that does things wrong when someone follows what's common practice on other systems (well, Ubuntu). >> Instead of a patchwork of hacks to address individual cases such as >> pip3, why not seek a general solution? Perhaps a database of >> checksums for dnf-managed files that a dnf utility could verify, >> report errors, and restore from repositories when ordered to do so. That could make a good feature request for DNF. This Change is about not overwriting DNF-installed files in the first place, not about checking system integrity. We're trying to not make this a patchwork of hacks, but rather a set of configuration options plus upstream-bound patches to support that config. Unfortunately, we need this fix in Fedora faster than we can push it upstream (where we need to also consider Windows, etc), to prevent unsuspecting people from breaking their systems. Our first plan was to find an upstream solution for this, we surveyed many previous discussions and possibile solutions. However, this problem is too distro-specific for a global upstream change to happen in reasonable time frame. This Change we proposed seems to fix the problem and doesn't greatly diverge from upstream. The /usr/local/.../site-packages directory will be shared between all pip-installed modules, whether installed using the packaged python3-pip, or installed by pip run on Python 3 (of the same version) compiled from source with the prefix /usr/local. This could be a problem if the user wants to pip install one version of a package for the packaged Python 3.x and a different version for the Python 3.x compiled from source. (Note that with different minor versions, e.g. 3.5 and 3.6, there are no problems as these have separate module directories.) However, this potential conflict is a small corner case compared to the number of users who accidentally break their system by running sudo pip. [0] More precise description and disccusion related to this change can be found at python-devel mailing list thread [1] [0] For example: * https://bugzilla.redhat.com/show_bug.cgi?id=1396158 * https://bugzilla.redhat.com/show_bug.cgi?id=1397575 * https://bugzilla.redhat.com/show_bug.cgi?id=1400377 * More: https://www.google.cz/search?q="sudo+pip"+site%3Abugzilla.redhat.com And there are many anecdotal stories of frustrated users who didn't report [1] https://lists.fedoraproject.org/archives/list/python-devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/3ZB2AZ77WN53E3XOB4AU7XKCJOJVHHHE/ Change owners _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
