Pypi source does not include tests folder so they had to be manually
downloaded from GitHub. This commit replaces pypi source with tarball
from GitHub where tests are included.
This also fixes rpmlint invalid-url warning.
There are four different executables for python-pip, but so far only two of
them had man page. This commit makes man page available for rest of the
executables via links.
Some patches touch tests and we didn't include the test sources --without tests,
leading to broken build. This was a long standing reoccurring problem.
Now we always include and unpack tests sources, even when we don't run them.
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1793456
The main() wrapper moved the import path again, this time with compatibility shim:
- we still need pip-allow-different-versions.patch to support older pips installed by users
- we dropped callable-main.patch - the shim is provided by pip for all previous paths
- no need to patch older pips to support user installed pip 20+
- no need to patch Pythons (or virtualenv) to support pip 20+ wheel in ensurepip
There is no point of building this without python3 and this makes
the spec a bit more readable.
Also:
- only have one %python_wheelname (can be split in future if needed)
- use pythonX -m pytest instead of py.test-X.Y
This is a fix for https://bugzilla.redhat.com/show_bug.cgi?id=1573755
1. We put "rpm" inside pip's INSTALLER instead of "pip"
2. From pip, we check what's in INSTALLER and only show the warning
if it's "pip".
When a venv is cearted, pip is installed from wheel (trough rewheel),
INSTALLER contains "pip".
When virtualenv is used, pip is installed from the Interwebz via pip,
so INSTALLER contains "pip".
Upstream issue https://github.com/pypa/pip/issues/5346
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.