Python-future: The new magic "configparser" import breaks the "configparser" backport

Also, on the backport repo people already report this not working: https://bitbucket.org/ambv/configparser/issue/8/configparser-import-broken-on-py27

For the time being I had to remove the dependency on python-future in configparser to make it work.

+1

More generally, python-future should not install modules that shadow other installed modules IMO. Most of the other ones are less likely to be issues, so it might be preferable to just do that rather than adding a faux dependency.

@ambv, @Julian: Thanks for your feedback. I would like to fix this but I don't yet see the right way to proceed. Here are the options as I see it:

1. Remove configparser from python-future and change the docs to recommend using your configparser package instead. This may make sense, but not unless configparser is a drop-in replacement for ConfigParser on Py2.7. Currently, there are 14 failures and 9 errors when running test_cfgparser.py on Python 2.7.9 with the configparser package installed after replacing import ConfigParser with import configparser as ConfigParser. With python-future and its simple configparser alias installed, all the same tests pass.
2. Change setup.py in python-future to install the configparser alias package only if a module or package of the same name doesn't exist. The drawback to this would be that the packages installed would depend on the order in which they are listed in requirements.txt. Even worse, I believe pip does not guarantee to install packages in the order that they appear in requirements.txt. If both configparser and future were listed, this would lead to the set of packages installed by pip being non-deterministic.
3. Use the extras feature of setuptools to support an install option such as pip install future[without_configparser].

Do you think the configparser package could be modified so that the Python 2.7.9 test suite passes when using it? This would give me confidence in recommending it for a smooth upgrade path for Py2 code that currently uses ConfigParser.

With time passing, more and more persons directly use the configparser backport, because that's the way to use the latest upstream API (and features) while still being on Python 2.x.

Thus I don't really understand the relevance of your failing tests. If you want the old API, you use the old module name. If you want the new API, you use the new name. It no longer makes sense to put the 2.x ConfigParser at the place where its Python 3 replacement is.

It would be nice to have a fix for this as I got a report about this in Kali https://bugs.kali.org/view.php?id=3245 and in a typical Kali Linux system I have packages that need both python-future and python-configparser. Except that the latter is broken for anyone using it on Python 2.x due to this bug.

So to sum it up, I think you should implement (1) and drop the tests about configparser. (2) is no a no-go as Debian packages are built in minimal environments and python-configparser would not be available when setup.py is run. (3) is possible but it means that python-future's API varies depending on how it has been installed. It's really not a good idea as a distribution can only have it installed one way.

Thank you! cc @sbrun

Currently, for example, Fedora simply patches out configparser since they've also got the backport available.

FWIW, I'm currently going through upstream fixes that I need to merge to the backport and will release the configparser backport 3.5.1 tomorrow. As for python-future, I also think it should implement (1).

Thanks for your input, everyone!

I'm willing to remove configparser from python-future in v0.16. I've got a branch in progress: https://github.com/PythonCharmers/python-future/tree/v0.16.x.

I came here trying to figure out why ConfigParser.read_dict stopped working on my machine.

Turns out one of the packages I use started depending on python-future (specifically some part of QGIS), and then I got hit by this issue because the version of ConfigParser in Python 2.7 doesn't implement the complete API of ConfigParser in Python 3.x.

I resolved this by locking the python-future version of the package:

sudo chmod 000 /usr/lib/python2.7/dist-packages/configparser/

Flake8 recently added a dependency on the configparser backport that @ambv generously maintains. Some users also had this module installed which broke existing, tested, and documented behaviour of Flake8. This is a problem for us, and I'm now going to start adding documentation to Flake8 to explain why people might see a problem. Future will be specifically mentioned to help users avoid this hassle.

@sigmavirus24 Ian, you can work around this for now by depending on the configparser backport and using the from backports import configparser form. This was specifically implemented to unblock situations like these :(

@ambv thanks! I didn't realize I could do that.

I've now released v0.16.0, which removes configparser. The docs also recommend using Lukasz's backport. Thanks for your feedback, everyone!

Thanks @edschofield!