`--extra-index-url` not working for PIP
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| python-pip (Ubuntu) |
High
|
James Page |
Bug Description
I originally wrote this as a comment on
https:/
guess it makes sense to open a new separate bug since the other report was
already closed. Pasting my comment contents below.
~$ lsb_release -rd
Description: Ubuntu 18.04.2 LTS
Release: 18.04
~$ apt-cache policy python3-pip
python3-pip:
Installed: 9.0.1-2.
Candidate: 9.0.1-2.
Version table:
*** 9.0.1-2.
500 http://
500 http://
100 /var/lib/
9.0.1-2 500
500 http://
500 http://
---
It seems like `9.0.1-
functionality of PIP.
In my understanding, the idea is for `--extra-index-url` to provide a
PyPI-compliant repository that offers a few additional packages, allowing PIP
to fall back onto the instance configured as `--index-url` (defaults to
upstream PyPI). This has been the case with earlier versions, allowing us to
host an internal PyPI repository containing a subset of packages, as well as a
generic local caching PyPI mirror.
In `9.0.1-
work properly, instead failing if _either_ the `--index-url` _or_
`--extra-index-url` instances lack the package.
---
With `~/.config/
[global]
index-url = https://<user>:
extra-index-url = https://<user>:
With `python3-pip` version `9.0.1-
~$ python3 -m venv env/pip-latest
~$ . env/pip-
(pip-latest) ~$ pip --version
pip 9.0.1 from /home/dandersso
(pip-latest) ~$ pip install hpt
Collecting hpt
Exception:
Traceback (most recent call last):
File "/home/
status = self.run(options, args)
File "/home/
File "/home/
File "/home/
File "/home/
File "/home/
self.link = finder.
File "/home/
File "/home/
for page in self._get_
File "/home/
page = self._get_
File "/home/
return HTMLPage.
File "/home/
File "/home/
raise HTTPError(
requests.
PIP fails with a traceback due to not finding `hpt` on the `--index-url`
instance -- but the point of giving `--extra-index-url` is that `hpt` resides
on that instance.
Trying to install a package that should be present on the `--index-url`
instance:
(pip-latest) ~$ pip install requests
Collecting requests
Exception:
Traceback (most recent call last):
File "/home/
status = self.run(options, args)
File "/home/
File "/home/
File "/home/
File "/home/
File "/home/
self.link = finder.
File "/home/
File "/home/
for page in self._get_
File "/home/
page = self._get_
File "/home/
return HTMLPage.
File "/home/
File "/home/
raise HTTPError(
requests.
Now it fails with a traceback since `requests` does not exist on the
`--extra-index-url` instance, but the purpose of that instance is to provide a
small subset of extra packages, not to be a full mirror.
Changing `~/.config/
[global]
index-url = https://<user>:
removing the `--extra-index-url` instance altogether, it behaves as expected,
not finding the `hpt` package, but being able to install `requests`:
(pip-latest) ~$ pip install hpt
Collecting hpt
Exception:
Traceback (most recent call last):
File "/home/
status = self.run(options, args)
File "/home/
File "/home/
File "/home/
File "/home/
File "/home/
self.link = finder.
File "/home/
File "/home/
for page in self._get_
File "/home/
page = self._get_
File "/home/
return HTMLPage.
File "/home/
File "/home/
raise HTTPError(
requests.
It is expected to not be able to install `hpt`, but PIP should not fail with a
traceback, but just with a diagnostic message like `No matching distribution
found for hpt`.
Installing a common package will correctly use the `--index-url` instance:
(pip-latest) ~$ pip install requests
Collecting requests
Using cached https:/
Collecting idna<2.9,>=2.5 (from requests)
Using cached https:/
Collecting certifi>=2017.4.17 (from requests)
Using cached https:/
Collecting urllib3!
Using cached https:/
Collecting chardet<
Using cached https:/
Installing collected packages: idna, certifi, urllib3, chardet, requests
Successfully installed certifi-2019.6.16 chardet-3.0.4 idna-2.8 requests-2.22.0 urllib3-1.25.3
---
Downgrading `python3-pip` to `9.0.1-2`:
~$ sudo apt install python3-pip=9.0.1-2 python-
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be DOWNGRADED:
python-
0 upgraded, 0 newly installed, 2 downgraded, 0 to remove and 5 not upgraded.
Need to get 1 493 kB of archives.
After this operation, 226 kB disk space will be freed.
Do you want to continue? [Y/n]
Get:1 http://
Get:2 http://
Fetched 1 493 kB in 0s (4 177 kB/s)
dpkg: warning: downgrading python3-pip from 9.0.1-2.
(Reading database ... 196581 files and directories currently installed.)
Preparing to unpack .../python3-
Unpacking python3-pip (9.0.1-2) over (9.0.1-
dpkg: warning: downgrading python-pip-whl from 9.0.1-2.
Preparing to unpack .../python-
Unpacking python-pip-whl (9.0.1-2) over (9.0.1-
Setting up python-pip-whl (9.0.1-2) ...
Setting up python3-pip (9.0.1-2) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
and retrying the first attempt with `~/.config/
[global]
index-url = https://<user>:
extra-index-url = https://<user>:
yields a session like:
~$ python3 -m venv env/pip-previous
~$ . env/pip-
(pip-previous) ~$ pip --version
pip 9.0.1 from /home/dandersso
(pip-previous) ~$ pip install hpt
Collecting hpt
Using cached https:/
Collecting argh (from hpt)
Using cached https:/
Collecting pyyaml==5.1 (from hpt)
Using cached https:/
Collecting argcomplete (from hpt)
Using cached https:/
Collecting distro (from hpt)
Using cached https:/
Collecting requests (from hpt)
Using cached https:/
Collecting termcolor (from hpt)
Using cached https:/
Collecting cilib==v0.1.397 (from hpt)
Using cached https:/
Collecting idna<2.9,>=2.5 (from requests->hpt)
Using cached https:/
Collecting chardet<
Using cached https:/
Collecting certifi>=2017.4.17 (from requests->hpt)
Using cached https:/
Collecting urllib3!
Using cached https:/
Collecting hvac (from cilib==
Using cached https:/
Collecting psycopg2-binary (from cilib==
Using cached https:/
[...SNIP...]
Successfully installed argcomplete-1.10.0 argh-0.26.2 certifi-2019.6.16 chardet-3.0.4 cilib-0.1.397 distro-1.4.0 hpt-0.1.397 hvac-0.9.2 idna-2.8 psycopg2-
PIP now correctly resolves the respective packages to their respective
instances, using `--extra-index-url` for the packages that are _only_ present
there, and falling back to `--index-url` for everything else.
Changing `~/.config/
[global]
index-url = https://<user>:
cleaning out the virtual environment and trying again:
(pip-previous) ~$ deactivate
~$ rm -rf env/pip-previous/
~$ python3 -m venv env/pip-previous
~$ . env/pip-
(pip-previous) ~$ pip --version
pip 9.0.1 from /home/dandersso
(pip-previous) ~$ pip install hpt
Collecting hpt
Could not find a version that satisfies the requirement hpt (from versions: )
No matching distribution found for hpt
(pip-previous) ~$ pip install requests
Collecting requests
Using cached https:/
Collecting chardet<
Using cached https:/
Collecting urllib3!
Using cached https:/
Collecting certifi>=2017.4.17 (from requests)
Using cached https:/
Collecting idna<2.9,>=2.5 (from requests)
Using cached https:/
Installing collected packages: chardet, urllib3, certifi, idna, requests
Successfully installed certifi-2019.6.16 chardet-3.0.4 idna-2.8 requests-2.22.0 urllib3-1.25.3
---
In summary, from my point-of-view, the `9.0.1-
breaks all functionality related to `--extra-
the behaviour when a package is not found when using `--index-url`.
I will be happy to provide any additional information that can help.
information type: | Public → Public Security |
information type: | Public Security → Private Security |
information type: | Private Security → Public |
Valtteri Mäkelä (vltrrr) wrote : | #2 |
Confirmed also with Mint 19.1 with latest packages, if using our internal pypi server. Creating a plain py3 virtualenv fails:
$ virtualenv testenv --python python3
Fails with:
File "/home/
raise HTTPError(
requests.
Disabling the internal pypi server from ~/.pip/pip.conf works, but of course removes access to internal packages.
Downgrading to previous version as suggested by Daniel Anderson resolved the issue:
sudo apt install python3-pip=9.0.1-2 python-
Marc Mercer (daemoen) wrote : | #3 |
Can confirm here as well. I also tested the pip/whl builds from universal which are at 18.x -- these unfortunately have the exact same issue. Was hoping maybe they had moved past it, which suggests that the issue is with the unvendored requests, as opposed to pip itself. https:/
tags: | added: regression-update |
Johnny (jairoalonso25) wrote : | #4 |
Can Confirm. Using a private PyPI repo in my company.
pip install --extra-index-url=https:/
Collecting alps
Exception:
Traceback (most recent call last):
File "/usr/lib/
status = self.run(options, args)
File "/usr/lib/
wb.
File "/usr/lib/
self.
File "/usr/lib/
ignore_
File "/usr/lib/
require_hashes
File "/usr/lib/
self.link = finder.
File "/usr/lib/
all_candidates = self.find_
File "/usr/lib/
for page in self._get_
File "/usr/lib/
page = self._get_
File "/usr/lib/
return HTMLPage.
File "/usr/lib/
resp.
File "/usr/share/
raise HTTPError(
HTTPError: 404 Client Error: Not Found for url: https:/
File "/usr/lib/
require_hashes
File "/usr/lib/
self.link = finder.
File "/usr/lib/
all_candidates = self.find_
File "/usr/lib/
for page in self._get_
File "/usr/lib/
page = self._get_
File "/usr/lib/
return HTMLPage.
File "/usr/lib/
resp.
File "/usr/share/
raise HTTPError(
requests.
lsb_release -rd
Description: Ubuntu 18.04.3 LTS
Release: 18.04
Using WLS form Windows 10
James Page (james-page) wrote : | #5 |
I'm slightly baffled by this as the original bug report and associated fix resolved an issue where:
requests.
was not the same as requests.HTTPError in the distro packaging - but the exception raised in this bug report infers that something is still wonky in the debundling of the vendored requests...
James Page (james-page) wrote : | #6 |
Struggling to reproduce this issue; I've setup a test instance with a extra-index-url which points to an empty index; this throws a 404 when accessed for the modules being requested but the exception handler is correctly catching the exception, falling back to the main package index.
James Page (james-page) wrote : | #7 |
404 Client Error: Not Found for url: http://
Traceback (most recent call last):
File "/root/
resp.
File "/root/
raise HTTPError(
pip._vendor.
As you can see the correct/vendor path-ed exception is being raised and caught.
Changed in python-pip (Ubuntu): | |
status: | Confirmed → Incomplete |
Marc Mercer (daemoen) wrote : | #8 |
@james-page I think the thing being overlooked is what it is doing, not wether or not the exception is correct. In our case, we have repositories that have some artifacts, and repositories that may have other artifacts... (and once in a rare while, overlap with different versions).. If we request a package that does *not* exist in the custom urls, then it will fail completely, instead of passing with the only failure being on that one repository. By default, it should check each of the repositories, see if they have it, etc.. It seems to be checking them all, but if *any* of them fails to have an artifact being requested, the entire pip operation implodes, even if the package *is* available in a different repository successfully prior to the fetching of the failed repo.
James Page (james-page) wrote : | #9 |
The exception drives the behaviour so the behaviour and the incorrect exception class are linked - the pip index.py code is mismatching on the type HTTPError resulting in an unhandled exception and the behaviour you are seeing.
I can't reproduce this at the moment so there must be something we're missing.
James Page (james-page) wrote : | #10 |
https:/
James Page (james-page) wrote : | #11 |
I believe this is something todo with missing vendor pathing for requests.
I've picked the commit in #10 into the bionic package and uploaded to:
https:/
as I'm unable to reproduce the issue it would be helpful if one of the impacted bug participants could verify it resolves the issue.
Changed in python-pip (Ubuntu): | |
status: | Incomplete → New |
importance: | Undecided → High |
Changed in python-pip (Ubuntu): | |
status: | New → Incomplete |
assignee: | nobody → James Page (james-page) |
Marc Mercer (daemoen) wrote : | #12 |
@james-page Tested -- not fixed
root@vagrant:/etc# dpkg -l | grep pip
ii libpipeline1:amd64 1.5.0-1 amd64 pipeline manipulation library
ii python-pip 9.0.1-2.
ii python-pip-whl 9.0.1-2.
ii python3-pip 9.0.1-2.
root@vagrant:/etc# pip install ansible==2.8.0
Collecting ansible==2.8.0
Exception:
Traceback (most recent call last):
File "/usr/lib/
status = self.run(options, args)
File "/usr/lib/
wb.
File "/usr/lib/
self.
File "/usr/lib/
ignore_
File "/usr/lib/
require_hashes
File "/usr/lib/
self.link = finder.
File "/usr/lib/
all_candidates = self.find_
File "/usr/lib/
for page in self._get_
File "/usr/lib/
page = self._get_
File "/usr/lib/
return HTMLPage.
File "/usr/lib/
resp.
File "/usr/share/
raise HTTPError(
HTTPError: 404 Client Error: Not Found for url: https:/
Marc Mercer (daemoen) wrote : | #13 |
@james-page -- Please ping me on freenode (Daemoen) on the ubuntu channel. I have created a user for you to test against our repository host, as hopefully that should simplify this a bit. I can provide you all of the details for the configuration needed, but don't want to provide them here as this is a public medium. I just tested the credentials and ensured that it will allow you to replicate the issue as the rest of us see it.
chbrosso (chbrosso) wrote : | #14 |
It looks like the upstream issue is here, and it mentions that it's a vendoring issue:
Akkana Peck (akkzilla) wrote : | #15 |
This might be a simpler way to reproduce it. I uploaded a package to test.pypi and wanted to use --extra-index-url to verify that its dependencies are pulled in (it has dependencies that are in pypi but not in test.pypi). Here are my steps to reproduce it:
python3 -m venv /tmp/test3env
source /tmp/test3env/
pip install wheel
pip install --index-url https:/
which gives the error:
Could not install packages due to an EnvironmentError: 404 Client Error: Not Found for url: https:/
Sometimes it errors on a different package, not always pycairo, but the rest of the error is the same. I filed https:/
Changed in python-pip (Ubuntu): | |
status: | Incomplete → Confirmed |
chbrosso (chbrosso) wrote : | #16 |
A simple command to test for the issue is pip install --index-url https:/
@james-page I tested your proposed PPA with this command, and the issue is still here.
I gave a shot to this, and generated a patch from the upstream pull request https:/
I'm unable to further propose a new package as I'm not used to contributing fixes, but would be happy to if necessary.
The attachment "Fix-1833229.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]
tags: | added: patch |
chbrosso (chbrosso) wrote : | #18 |
@james-page (or any other maintainer), did you have a chance to look at the patch? I'm pretty confident it solves the issue.
James Page (james-page) wrote : | #19 |
sorry - I missed this update - looking now!
James Page (james-page) wrote : | #20 |
pip right through to Ubuntu development appears to be missing part of the fix for this problem so I've picked fixes for bionic/eoan/focal into:
https:/
I'm still not able to reproduce this issue but please test and see if the proposed version resolves this issue with the test case in #16.
James Page (james-page) wrote : | #21 |
Right - I was able to reproduce this issue on focal using:
python3 -m venv /tmp/test3env
source /tmp/test3env/
pip install wheel
pip install --index-url https:/
(thanks for that)
However with the patched package in the PPA, I now hit a completely different problem with the test case which looks related to the patch:
Traceback (most recent call last):
File "/usr/lib/
import pip._internal
File "<frozen zipimport>", line 259, in load_module
File "/tmp/tmpzye4xj
File "<frozen zipimport>", line 259, in load_module
File "/tmp/tmpzye4xj
File "<frozen zipimport>", line 259, in load_module
File "/tmp/tmpzye4xj
File "<frozen zipimport>", line 259, in load_module
File "/tmp/tmpzye4xj
File "<frozen zipimport>", line 259, in load_module
File "/tmp/tmpzye4xj
ModuleNotFoundE
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/
return _run_code(code, main_globals, None,
File "/usr/lib/
exec(code, run_globals)
File "/usr/lib/
sys.
File "/usr/lib/
return _bootstrap(
File "/usr/lib/
return _run_pip(args + _PROJECTS, additional_paths)
File "/usr/lib/
return pip.main(args)
AttributeError: module 'pip' has no attribute 'main'
unknown (charstar) wrote : | #22 |
Applying https:/
Before:
$ pip3 install --trusted-host packages.
Collecting talos-mrt
Exception:
Traceback (most recent call last):
File "/usr/lib/
status = self.run(options, args)
File "/usr/lib/
wb.
File "/usr/lib/
self.
File "/usr/lib/
ignore_
File "/usr/lib/
require_hashes
File "/usr/lib/
self.link = finder.
File "/usr/lib/
all_candidates = self.find_
File "/usr/lib/
for page in self._get_
File "/usr/lib/
page = self._get_
File "/usr/lib/
return HTMLPage.
File "/usr/lib/
resp.
File "/usr/share/
raise HTTPError(
requests.
After:
$ pip3 install --trusted-host packages.
Collecting talos-mrt
Downloading http://
...
Building wheels for collected packages: talos-mrt, ...
...
Successfully built talos-mrt ...
Thanks!
Gerard Weatherby (gweatherby) wrote : | #23 |
To make this copy-and-paste obvious for the next person to come by:
add-apt-repository ppa:ci-
apt update
apt install python3-pip
Akkana Peck (akkzilla) wrote : | #24 |
When I use the python3-pip from ppa:ci-
/usr/bin/pip3 install --index-url https:/
in a virtualenv that's brand new except that I've installed wheel, I get:
Looking in indexes: https:/
Requirement already satisfied: metapho in /home/akkana/
Requirement already satisfied: pycairo in /usr/lib/
Requirement already satisfied: PyGObject in /usr/lib/
Is that what it's supposed to do? I created the virtualenv with python3 -m venv /tmp/testpythonenv, no --system-
Does anyone know if this is thought to be fixed in Fossa?
Scott Kitterman (kitterman) wrote : | #25 |
The fix was included in pip 20.0.2 brought in from Debian:
python-pip | 20.0.2-5ubuntu1 | focal/universe | source
python-pip | 20.0.2-5ubuntu1 | groovy/universe | source
Changed in python-pip (Ubuntu): | |
status: | Confirmed → Fix Released |
andrei (akela1101) wrote : | #26 |
I'm not sure how the LTS system works, but for me this doesn't look Fixed if bug is still present in bionic.
I guess, a quick workaround is to put pip2 >=20.0.2 whl to the extra-index-url repo and use it.
Gerard Weatherby (gweatherby) wrote : | #27 |
It appears the ppa is no longer "just working" because the mainline bionic Ubuntu version of python3-pip has incremented. That is to say, even after adding the ppa and doing apt update, apt-get install pulls the buggy one from the mainline repo.
I was able to get the right version by using:
apt install python3-
Gerard Weatherby (gweatherby) wrote : | #28 |
To stop automatic updates from overwriting the bug fix version of python3-pip, create file
/etc/apt/
Package: python3-pip
Pin: origin "ppa.launchpad.net"
Pin-Priority: 700
Gerard Weatherby (gweatherby) wrote : | #29 |
Yesterday's (10-13) update of the PPA has broken the fix.
Status changed to 'Confirmed' because the bug affects multiple users.