python-pip/pip-allow-older-versions.patch

--- /usr/bin/pip3	2018-03-29 15:22:13.000000000 +0200
+++ pip3	2018-05-04 11:49:08.098821010 +0200
@@ -4,7 +4,12 @@
 import re
 import sys
 
-from pip._internal import main
+try:
+    from pip._internal import main
+except ImportError:
+    # user has most probably downgraded pip in their home
+    # so let them run it anyway until ~/.local/bin makes it in front of the PATH
+    from pip import main
 
 if __name__ == '__main__':
     sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
Allow to import pip10's main from pip9's /usr/bin/pip Users are upgrading pip9 to pip10 by various manners, one of them is `pip install --user --upgrade pip`. If they do that and they run `pip` or `pip3`, the one from /usr/bin is used. However that's the one from this RPM package (pip9) and the import in there fails (it tries to import from ~/.local, but pip10 is there with a bit different API). We add a patch as a dirty workaround to make /usr/bin/pip* work with both pip9 (from this RPM) and pip10 (from whatever). A proper fix is to put ~/.local/bin in front of /usr/bin in the PATH, however others are against that and we cannot change it for existing installs/user homes anyway. This is a workaround for: * https://bugzilla.redhat.com/show_bug.cgi?id=1569488 * https://bugzilla.redhat.com/show_bug.cgi?id=1571650 Patch is applied in %install, because /usr/bin/pip* are entrypoints. 2018-05-04 10:11:26 +00:00			`--- /usr/bin/pip3 2018-03-29 15:22:13.000000000 +0200`
			`+++ pip3 2018-05-04 11:49:08.098821010 +0200`
			`@@ -4,7 +4,12 @@`
			`import re`
			`import sys`

Update to 18.0 2018-07-23 15:22:50 +00:00			`-from pip._internal import main`
Allow to import pip10's main from pip9's /usr/bin/pip Users are upgrading pip9 to pip10 by various manners, one of them is `pip install --user --upgrade pip`. If they do that and they run `pip` or `pip3`, the one from /usr/bin is used. However that's the one from this RPM package (pip9) and the import in there fails (it tries to import from ~/.local, but pip10 is there with a bit different API). We add a patch as a dirty workaround to make /usr/bin/pip* work with both pip9 (from this RPM) and pip10 (from whatever). A proper fix is to put ~/.local/bin in front of /usr/bin in the PATH, however others are against that and we cannot change it for existing installs/user homes anyway. This is a workaround for: * https://bugzilla.redhat.com/show_bug.cgi?id=1569488 * https://bugzilla.redhat.com/show_bug.cgi?id=1571650 Patch is applied in %install, because /usr/bin/pip* are entrypoints. 2018-05-04 10:11:26 +00:00			`+try:`
Update to 18.0 2018-07-23 15:22:50 +00:00			`+ from pip._internal import main`
Allow to import pip10's main from pip9's /usr/bin/pip Users are upgrading pip9 to pip10 by various manners, one of them is `pip install --user --upgrade pip`. If they do that and they run `pip` or `pip3`, the one from /usr/bin is used. However that's the one from this RPM package (pip9) and the import in there fails (it tries to import from ~/.local, but pip10 is there with a bit different API). We add a patch as a dirty workaround to make /usr/bin/pip* work with both pip9 (from this RPM) and pip10 (from whatever). A proper fix is to put ~/.local/bin in front of /usr/bin in the PATH, however others are against that and we cannot change it for existing installs/user homes anyway. This is a workaround for: * https://bugzilla.redhat.com/show_bug.cgi?id=1569488 * https://bugzilla.redhat.com/show_bug.cgi?id=1571650 Patch is applied in %install, because /usr/bin/pip* are entrypoints. 2018-05-04 10:11:26 +00:00			`+except ImportError:`
Update to 18.0 2018-07-23 15:22:50 +00:00			`+ # user has most probably downgraded pip in their home`
Allow to import pip10's main from pip9's /usr/bin/pip Users are upgrading pip9 to pip10 by various manners, one of them is `pip install --user --upgrade pip`. If they do that and they run `pip` or `pip3`, the one from /usr/bin is used. However that's the one from this RPM package (pip9) and the import in there fails (it tries to import from ~/.local, but pip10 is there with a bit different API). We add a patch as a dirty workaround to make /usr/bin/pip* work with both pip9 (from this RPM) and pip10 (from whatever). A proper fix is to put ~/.local/bin in front of /usr/bin in the PATH, however others are against that and we cannot change it for existing installs/user homes anyway. This is a workaround for: * https://bugzilla.redhat.com/show_bug.cgi?id=1569488 * https://bugzilla.redhat.com/show_bug.cgi?id=1571650 Patch is applied in %install, because /usr/bin/pip* are entrypoints. 2018-05-04 10:11:26 +00:00			`+ # so let them run it anyway until ~/.local/bin makes it in front of the PATH`
Update to 18.0 2018-07-23 15:22:50 +00:00			`+ from pip import main`
Allow to import pip10's main from pip9's /usr/bin/pip Users are upgrading pip9 to pip10 by various manners, one of them is `pip install --user --upgrade pip`. If they do that and they run `pip` or `pip3`, the one from /usr/bin is used. However that's the one from this RPM package (pip9) and the import in there fails (it tries to import from ~/.local, but pip10 is there with a bit different API). We add a patch as a dirty workaround to make /usr/bin/pip* work with both pip9 (from this RPM) and pip10 (from whatever). A proper fix is to put ~/.local/bin in front of /usr/bin in the PATH, however others are against that and we cannot change it for existing installs/user homes anyway. This is a workaround for: * https://bugzilla.redhat.com/show_bug.cgi?id=1569488 * https://bugzilla.redhat.com/show_bug.cgi?id=1571650 Patch is applied in %install, because /usr/bin/pip* are entrypoints. 2018-05-04 10:11:26 +00:00
			`if __name__ == '__main__':`
			`sys.argv[0] = re.sub(r'(-script\.pyw?\|\.exe)?$', '', sys.argv[0])`