pip: pip silently fails to install extras and returns error code

It seems that pip just returns success code on anything related to use of extras, commands like: pip install -e .[non_exiting_extra] reports success.

Even worse, with existing extras that may fail to install, the final result code is still a success, when in fact pip failed to install dependencies.

This is a critical bug because it directly affect CI usage where we can no longer trust result code from pip, bugs may go in unnoticed.

About this issue

Original URL
State: open
Created 5 years ago
Reactions: 8
Comments: 24 (22 by maintainers)

Most upvoted comments

I don’t know a lot about the tradeoffs but I’ll add one more vote for changing this from a warning to an error. I probably should understand this better, but apparently if any transitive dependency is installed with an invalid extra you won’t be able to load entrypoints from an upstream package. e.g. Lets say package A depends on package B, and B requires C[invalid_extra], package A also has entrypoint "my_group": "my_extra=A.foo.Bar" Running

from pkg_resources import iter_entry_points
print([e.load() for e in iter_entry_points('my_group', 'my_extra')])

will give

pkg_resources.UnknownExtra: C X.X.X has no such extra feature 'invalid_extra'

This is a bug in package B, but it would be easy for it to slip through their CI unless someone happened to know this behavior (which is unexpected to me). Having pip error out on missing extras would make this easier to catch.

hudsonft on Jan 13, 2022

Not fully ignore - I believe we trace a warning.

Returning non-zero would be backwards incompatible. I would be +1 on doing it (even aborting installation if we are not able to find an extra), but it would need to be changed over at least 1-2 releases. The first step would be to add to the existing warning to say that it’s unsupported and will fail in a future release. We’d also want to go through pypi and see how many packages make reference to nonexistent extras.

chrahunt on Oct 1, 2019

Came here to also say that it should be an error.

In “real world” scenarios, the amount of pip output is very often well more than a screen full so even noticing the “warning” is hard in those cases.

It seems very obvious to me that if I ask pip, “please install X with extra foo” and it can’t do that (because there’s no “foo” extra, or any other reason) then it is an error.

Compounding this is the fact that there’s no way to ASK what the extras even are.

meejah on Oct 4, 2023

Yesterday I found case where latest pip went into endless loop trying to resolve dependencies when told to use new resolver. I did not had time to build a reproducer yet but this made me think that maybe the new resolver is not yet ready for prime time.

A couple of months back I started to add PIP_USE_FEATURE=2020-resolver to CI pipelines (usually in tox.ini) for hardening testing. It did uncover conflicts quite often and I suspect that on the day this will become default we will have a huge number of confused users.

I would personally promote more early testing, especially on CI more before doing the big switch.

ssbarnea on Oct 18, 2020