pip install exits successfully when arguments are invalid

[benesch]

$ pip install
You must give at least one requirement to install (see "pip help install")
$ echo $?
0

$ pip wheel
You must give at least one requirement to wheel (see "pip help wheel")
$ echo $?
0

This seems like a bug, considering:

$ pip install --noexist
-snip-
no such option: --noexist
$ echo $?
2

[benesch]

Thanks, @xavfernandez!

[jaraco]

I don't consider this behavior a bug, but a form of graceful degradation, handling install <nothing> as a degenerate case of install <things> where <things> is the empty set. This behavior is common in computer science and not at all unreasonable. It allows for usage like:

pip install $(some command that returns dynamic reqs)

Without the graceful degradation, for a script to handle the empty set without erroring, it first has to resolve $(some command that returns dynamic reqs), test that output, then conditionally invoke pip install based on the output. With graceful degradation, that command can be run as it appears naturally.

Another real-world example is rwt, where in the 1.14 release filters dependencies based on what's installed, and may invoke pip install with the empty set.

Additionally to consider, what does it mean to invoke install -r requirements.txt where that file is empty? Should that also return a non-zero exit code if the file is empty? Yet it doesn't.

$ touch empty.txt
$ pip install -r empty.txt
$ echo $?
0

I think the previous behavior was more consistent, powerful, and friendly.

[benesch]

The reason I filed this bug is because, previously, an empty pip install would print out You must give at least on requirement to install but exit successfully. This mismatch was a definite bug: either it should print the error message and exit with an error, or it should print no error message and exit successfully.

I agree there was an argument for pushing the behavior in either direction. But I think the UX for the end user here is really important. If an empty pip install prints no error message and exits successfully, you might mistakenly believe that the packages listed in requirements.txt have been installed. This is what happens with several other package managers, like npm and bundler. For the record, the reason that empty requirements files are not treated as an error is for precisely the use case you describe: requirements files are often automatically generated. (See the discussion here.)

I'd advocate for a flag like --allow-empty-requirements to support use cases like yours.

[jaraco]

it should print the error message and exit with an error

The message that was printed was rendered on my screen in yellow, indicating to me that it was a warning and not an error. Therefore, it's not even a mismatch. Of course, if you don't have the color highlighting, I could see how it might appear like an error. There are many other cases where pip outputs warnings but exits with a non-error status (such as warning about new versions available).

I'd advocate for a flag like --allow-empty-requirements to support use cases like yours.

Are you saying that it should also exit with a non-zero status code when requirements.txt is empty unless that flag is passed? Personally, I'd prefer one, consistent behavior, even if that's to fail on nothing to install.

Speaking of use-cases, what is the use-case for returning a non-zero exit code when no requirements are specified?

[pfmoore]

As someone who commented on the PR for this, I have some sympathy for @jaraco's position. The exit status is essentially for scripting use, the message for user consumption, so there's a justification for the warning + success status approach originally used.

I don't script pip in this way myself, so I don't have a vested interest in any particular result, but I just wanted to be clear on where I stand.