enum34 dependency breaks some installs

[murrple-1]

First off, I'm not convinced if this should be a bug report here, but at the very least, I can suggest it.

Essentially, it seems that installing enum34 in environments of Python 3.6 and above can break certain codebases (see: https://stackoverflow.com/q/43124775), including mine. It seems enum34 is often loaded/imported ahead of the standard-library's enum, and the APIs have slightly diverged since Python 3.4.

Now, you may be thinking, "I know, that's why there's a check in setup.py" (see: https://github.com/hynek/argon2_cffi/blob/master/setup.py#L98). However, this sort of protection seems to not work really well with the more "modern" packaging solutions, like pipenv and poetry (see: pypa/pipenv#924, python-poetry/poetry#758), because the python version running the setup.py may not be the same version being deployed, and as they generate consistent lockfiles, regardless of the running python version.

It seems a nuisance, as the onus maybe should be on the package managers to figure it out. However, I would like to suggest/request that

a) the support for pre-3.4 python versions be dropped by removing the dependency on enum34, or

b) the package be split between a enum34 installable and non-enum34 installable. I think this can be achieved pretty easily with the extras_require argument in setuptools, such that

pip install argon2-cffi

would install without enum34, and

pip install argon2-cffi[enum34]

would install with enum34. If it helps, this project showcases the usecase in action, and this code shows how it's done.

Or,

c) take advantage of environment markers in setup.py instead. I don't fully understand what that means or entails, so I have a hard time recommending it, but this comment seems to suggest it as an alternative to doing a sys.version_info check.

If a) or b) sound logical, I can submit a PR.

[murrple-1]

An example of the issue in action is available here: https://travis-ci.org/murrple-1/pipenv-issue-3

I have also opened an issue with pipenv to see if there is a better workaround that I missed.

[hynek]

Hmmm, so what triggers this problem for you is this:

 No binaries permitted for argon2-cffi

because argon2-cffi goes for great lengths to build wheels for all relevant platforms and the requirements should be encoded correctly in the wheels.

I suppose I need to additionally add protective markers for cases like yours.

[hynek]

I think 8eed81a should fix it. Is there a way for you to test against master?

[murrple-1]

Yes, that appears to work for me, and (if it means anything from a rando from the internet) I like the elegance of that solution.

Per your comment about the No binaries permitted for argon2-cffi, I was creating that contrived environment in Travis CI (see export PIP_NO_BINARY=argon2-cffi. I am building/testing my project on Cygwin, which is one of the few environments where this sort of issue would arise.

[hynek]

Cool, thanks!