pip install should exit with non-zero exit code when not given enough arguments

[vmalloc]

• Pip version: 9.0.1
• Python version: 3.6
• Operating system: Mac OS X 10.12 / Arch Linux

Description:

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

[obestwalter]

This is not all. I just tried:

$ pip
$ pip install

... they also print an error or help message but exit with 0 - on the other hand

$ pip search
$ pip show

... exit with 1.

[pradyunsg]

I have a feeling this is probably related to your shell environment... Could you please tell me what output you get for pip; echo $??

[obestwalter]

There is nothing too special about my environment. I am on Archlinux with zsh, Python 3.6.2 using virtualenv with virtualenvwrapper.

pip; echo $?

Usage:   
  pip <command> [options]

Commands:
  install                     Install packages.
  download                    Download packages.
  uninstall                   Uninstall packages.
  freeze                      Output installed packages in requirements format.
  list                        List installed packages.
  show                        Show information about installed packages.
  check                       Verify installed packages have compatible dependencies.
  search                      Search PyPI for packages.
  wheel                       Build wheels from your requirements.
  hash                        Compute hashes of package archives.
  completion                  A helper command used for command completion.
  help                        Show help for commands.

General Options:
  -h, --help                  Show help.
  --isolated                  Run pip in an isolated mode, ignoring environment variables and user configuration.
  -v, --verbose               Give more output. Option is additive, and can be used up to 3 times.
  -V, --version               Show version and exit.
  -q, --quiet                 Give less output. Option is additive, and can be used up to 3 times (corresponding to WARNING, ERROR, and CRITICAL logging levels).
  --log <path>                Path to a verbose appending log.
  --proxy <proxy>             Specify a proxy in the form [user:passwd@]proxy.server:port.
  --retries <retries>         Maximum number of retries each connection should attempt (default 5 times).
  --timeout <sec>             Set the socket timeout (default 15 seconds).
  --exists-action <action>    Default action when a path already exists: (s)witch, (i)gnore, (w)ipe, (b)ackup, (a)bort.
  --trusted-host <hostname>   Mark this host as trusted, even though it does not have valid or any HTTPS.
  --cert <path>               Path to alternate CA bundle.
  --client-cert <path>        Path to SSL client certificate, a single file containing the private key and the certificate in PEM format.
  --cache-dir <dir>           Store the cache data in <dir>.
  --no-cache-dir              Disable the cache.
  --disable-pip-version-check
                              Don't periodically check PyPI to determine whether a new version of pip is available for download. Implied with --no-index.
0

pip --version
pip 9.0.1 from /home/oliver/.virtualenvs/tmp/lib/python3.6/site-packages (python 3.6)

[pradyunsg]

Ah... Oh, I didn't understand what you posted.

Just to clarify - you're asking for normalisation of the error codes from pip, such that when there are situations where it exits because of lack of enough information it sets the error code as non-zero?

If so, I'm in favour. :)

[obestwalter]

Just to clarify - you're asking for normalisation of the error codes from pip

I personally never had a problem with it and it is not a pain point for me. I just found the original report by @vmalloc surprising and decided to check and see what else comes back with 0 when one would expect an error code.

I would propose to change the title of this issue to something like "pip returns with 0 in some cases, when the user might expect an error code" and fix that in one fell swoop as part of all the breaking changes for 10.0? I can't imagine people relying on pip returning zero, when doing something nonsensical, but the relevant XKCD always comes to my mind the second after I thought it ...

[vmalloc]

While I agree this is a corner case, I think all command-line tools should return a nonzero exit status if they failed to fulfill the user's request or did not receive enough information to do so. This is normal behavior for the vast majority of command-line tools nowadays, especially in UNIX-based environments.

We hit this by accident - since we run pip automatically and due to another bug did not pass enough arguments to it, and the command succeeded, hiding our real issue - so this is not an imaginary scenario like spacebar heating...

[obestwalter]

@vmalloc just to be clear: I completey agree with you. It just did not bite me yet in the case of pip, but fixing this for 10.0 would definitely be appreciated.

[pradyunsg]

fix that in one fell swoop as part of all the breaking changes for 10.0

+1

[vmalloc]

@obestwalter yeah I know. I just felt I had to state the case we encountered so that future readers of the thread won't get anchored on the xkcd reference :-)

[obestwalter]

What I tried to say with the XKCD reference was actually the complete opposite of how you understood it ... that fixing this might bite hypothetical users relying on the crazy behaviour that pip returns 0 in some error scenarios :)

[vmalloc]

@obestwalter oh sorry - so I really did misunderstand you. My bad.

[nirgilboa]

I tested this on the master - it is fixed.
Please see the following duplicate issue: #4210

[vipinvkmenon]

This issue still persists

[MPV]

2720 and #4210 are now fixed.

This seems to work fine now in pip version 10.0.0:

$ pip2 --version
pip 10.0.0 from /usr/local/lib/python2.7/dist-packages/pip (python 2.7)

$ pip2 install -U
ERROR: You must give at least one requirement to install (see "pip help install")

$ echo $?
1

@vmalloc Ready to close this one? 😊

[xavfernandez]

This appears to be fixed indeed.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.