3.1.1 is broken and we need a post release

[ssbarnea]

Invalid syntax is a good enough reason for making a new release. Some tools are requesting older versions for a reason (py27 compatbility). Please fix this in a post release.

  File "/Users/ssbarnea/.pyenv/versions/3.6.8/lib/python3.6/asyncio/__init__.py", line 21, in <module>
    from .base_events import *
  File "/Users/ssbarnea/.pyenv/versions/3.6.8/lib/python3.6/asyncio/base_events.py", line 17, in <module>
    import concurrent.futures
  File "/Users/ssbarnea/.pyenv/versions/3.6.8/lib/python3.6/site-packages/concurrent/futures/__init__.py", line 8, in <module>
    from concurrent.futures._base import (FIRST_COMPLETED,
  File "/Users/ssbarnea/.pyenv/versions/3.6.8/lib/python3.6/site-packages/concurrent/futures/_base.py", line 381
    raise exception_type, self._exception, self._traceback
                        ^
SyntaxError: invalid syntax

[ssbarnea]

It also worth mentioning that this module does not expose a version attribute, checking its version at runtime a real challenge.

[agronholm]

I have tried every venue for explaining that this is a backport and is NOT SUPPOSED to be installed on Python 3. I have two guards in setup.py against that (python_requires and a check against sys.version_info) to ensure that nobody accidentally installs this on Python 3. What must I do to get this through to people?

[agronholm]

As for the __version__ attribute, I don't see a problem here. Most libraries don't have a __version__ attribute. If you need to check it at run time for some reason, why not just:

import pkg_resources
print(pkg_resources.get_distribution('futures').parsed_version)

[ssbarnea]

@agronholm Are you aware that setup.py is not guaranteed to run on package installation? Dealing with packaging in python is not simple but is something we do have to do, or users will get back at us.

The reality is that metadata about this backport package is broken, if it would not be broken you would not see people installing this package on a platform that is not supported. Unsupported platforms are declared in metadata. Obviously that when the incompatibility is discovered post release, it is needed to make a correctional post release.

You could also go so far as hiding the 3.1.1 from pypi but this will likely bring more people back to you. Lucky for you there is a trick you can use to fix something that was already released, read https://www.python.org/dev/peps/pep-0440/ -- and pip respects it. This means that you could a publish a 3.1.1post0 version that addresses the issues (either corrected metadata or the syntax, or both), users will be able to use it.

As a maintainer you need to assure that metadata on pypi is correct,... and to cope with all that "love" you receive from users (sadly many forget that most of us do maintain these in our spare time).

Regarding packaging it, once done right, you will not need to blame others for installing it in unsupported scenarios (they will not be able to do it).

Note: I am not using it myself, but got pinged by others hitting the same issue. In fact is even worse because by not having it as a dependency I cannot ban it as packaging does not have support for "anti-dependencies".

[agronholm]

As the maintainer of the wheel library, I am quite aware of the realities of Python packaging. Can you point out any errors in the packaging metadata of the current release?