pip: programmatic install quiet option fails

Pip version: 9.0.1
Python version: 2.7.10
Operating system: macOS 10.12.6

Description:

calling

pip.main(['install',  '-q', '--user', 'doesnothing'])

fails with the following (note that I have replaced my home dir with ~ in the traceback for privacy)

Exception:
Traceback (most recent call last):
  File "~/Library/Python/2.7/lib/python/site-packages/pip-9.0.1-py2.7.egg/pip/basecommand.py", line 215, in main
    status = self.run(options, args)
  File "~/Library/Python/2.7/lib/python/site-packages/pip-9.0.1-py2.7.egg/pip/commands/install.py", line 324, in run
    requirement_set.prepare_files(finder)
  File "~/Library/Python/2.7/lib/python/site-packages/pip-9.0.1-py2.7.egg/pip/req/req_set.py", line 380, in prepare_files
    ignore_dependencies=self.ignore_dependencies))
  File "~/Library/Python/2.7/lib/python/site-packages/pip-9.0.1-py2.7.egg/pip/req/req_set.py", line 666, in _prepare_file
    check_dist_requires_python(dist)
  File "~/Library/Python/2.7/lib/python/site-packages/pip-9.0.1-py2.7.egg/pip/utils/packaging.py", line 48, in check_dist_requires_python
    feed_parser.feed(metadata)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/email/feedparser.py", line 177, in feed
    self._input.push(data)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/email/feedparser.py", line 99, in push
    parts = data.splitlines(True)
AttributeError: 'NoneType' object has no attribute 'splitlines'
2

What I’ve run:

Notably, this works fine from the CLI. It fails with either -q or --quiet and regardless of which position the option is placed in.

pip uninstall works fine from both code and the CLI passing the quiet flag in any form.

Seems like a bug. But odd that it’s freaking out on the email feedparser stuff. Perhaps the pip install command is expecting a newer version of that lib under some circumstance?

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 24 (14 by maintainers)

Most upvoted comments

raising an issue and seeing it nearly immediately closed for using something that was not documented to be forbidden or unsupported is kind of surprising and quite off-putting

That part’s on me. Sorry about that!

pradyunsg on Aug 27, 2017

@uchuugaka, some questions:

Please confirm what which pip and pip --version state
Please confirm what python -m pip --version states
Please confirm what python -c "import sys; print(sys.path)" displays
Please confirm if you have any *.py files in your current directory, and if so what their names are.

Please also refrain from heaping scorn on all of the people, myself and @pradyunsg included, who have spent literally many hours of their free time developing and supporting software which you are able to use at completely no charge. Your aggressively negative comments (“That’s really useless”, “Now I really feel more like writing a better package manager”, “Clearly pip really does need to be replaced”, etc.) are neither constructive nor fair, and do nothing to motivate anyone to help you. In fact, the need to deal with abuse like this is the sort of thing that makes it harder for us to get anyone else involved in helping support pip, exacerbating the lack of manpower issues which are fundamentally at the root of most of the unresolved problems with pip.

pfmoore on Aug 26, 2017

Wow. Why would it be unsupported? The docs say this? That’s really useless. None of pip’s dependencies take that approach. Wouldn’t you want to understand where a bug is? Why would you suggest starting a subprocess? That’s great for one off quick and dirty but a bad idea for building software that needs to be used by others. I was literally willing to get help and see about finding and fixing the bug. Now I really feel more like writing a better package manager. Clearly pip really does need to be replaced. It’s bad enough as it is and it’s the best Python has ever had.

On Aug 27, 2017, at 2:31, Pradyun Gedam notifications@github.com wrote:

Hi @uchuugaka!

Using pip in-process (i.e. using pip.main) is not a supported way of using pip. The only supported way is to use the CLI - you can use a subprocess to invoke pip.

So, unless you can reproduce this using a subprocess or on the CLI, this is not exactly a bug in pip - you’re using it in a way that is not supported by pip developers, even though it is possible to use it like that. As you’ve said this doesn’t reproduce when used via the CLI, I’m tagging this as invalid and closing it. We can still discuss if it’s closed. 😃

All that said, it would be difficult to help you out without some more context in this situation. It seems pip is tripping while trying to get the metadata for the distribution to be installed. Figuring out why that’s happening would take some debugging - which feels unnecessary since this problem vanishes if you use pip in a supported manner.

I’d suggest you try doing the following instead of using pip.main:

subprocess.call([‘/path/to/python’, ‘-m’, ‘pip’, ‘install’, ‘-q’, ‘–user’, ‘doesnothing’]) If the issue still persists, I’ll happily reopen and retag this issue. 😃

― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

uchuugaka on Aug 26, 2017