Favoring a pip-installed module over the standard library copy

Question

I've been digging into a Module was already imported warning I get when I run ipython and various other programs in Python 2.7:

$ ipython
[path to python]/lib/python2.7/site-packages/path.py:122:
UserWarning: Module argparse was already imported from [path to python]/lib/python2.7/argparse.pyc, but 
[path to python]/lib/python2.7/site-packages is being added to sys.path
  import pkg_resources

This stems from argparse being included both in the standard library and as a module from PyPI.

In my case, the stevedore package required the argparse module be installed. There's unsettled discussion on stevedore's development site about constraining this requirement to Python 2.6 (which didn't have argparse built-in), but stevedore is just an example: many packages require argparse, and some even require a version higher than what's bundled in the standard library. (For example, remotecv requires argparse>=1.2.1,<1.3.0, as of this writing.)

What's the most Pythonic way to deal with this warning, assuming you do want to keep using the third-party package?

• Suppress the warning?
• Uninstall the argparse module in defiance of requirements?
• Excise argparse from your standard library?
• Something else?

There are similar questions at “How do you correct Module already loaded UserWarnings in Python?” and “Module pytz was already imported.” I'll let the wise crowds decide if this is a duplicate, but I don't believe it is. Those were both asked 4+ years ago, the package distribution tools have changed (this isn't about distribute or .eggs), and though the warning is the same, I don't think they were caused by this overlapping stdlib/PyPI issue.

Heads up to anyone researching this: pip list may exclude argparse from its results (somewhat controversially).

Answer 1

I can't help with the previously installed argparse versions, but may be able to make few helpful observations.

ipython is a heavy user of argparse, though in its own way. It builds a parser from the config files, and uses that to process your commandline. So your commandline has a last minute chance to override many comfig options.

And %magic commands are parsed with a version of argparse.

Development of the PyPi version ceased once it became standard (Python 2.7). Version number in the standard is meaningless. It is still (in the latest Python 3.5).

In [4]: argparse.__version__
Out[4]: '1.1'

I don't know how it can be done, but any module that seeks to install argparse should first check the Python version. If it 2.7 or newer, it should use the standard argparse.

Keep in mind that the argparse module is one self contained file, argparse.py. In my experience ipython works fine with a copy of that file in my own current working directory. I do that all the time when testing patches for argparse bug/issues.

Other than 2.6 compatibility, I can't think of a reason why a package would want a PyPi version of argparse instead of the standard one. Does any of the discussions indicate what kinds of incompatibilities might arise?

According the current PyPi version (1.4) NEWS.txt, the repository is now

https://github.com/ThomasWaldmann/argparse

It may be work exploring there to see what compatibility issues there are between than and the standard version(s).

Both the PyPi version and the standard library have test_argparse.py unittest files. They could be used to test for compatibilities.