search

ionelmc / python-redis-lock

Lock context manager implemented via redis SET NX EX and BLPOP.
https://pypi.python.org/pypi/python-redis-lock
BSD 2-Clause "Simplified" License
543 stars 76 forks source link

Does 3.3.0 actually not work on Python 3.3? #77

Closed mrmachine closed 4 years ago

mrmachine commented 4 years ago

I understand that you may no longer support Python 3.3 in this version (though it was not mentioned in the changelog), but setup.py explicitly prohibits installation on 3.3 via python_requires. Looking at the commits in that release (since 3.2.0) I can see that it was dropped from the test grid, but nothing else obviously indicates that it won't actually run on Python 3.3 (if allowed to be installed).

I have an old project that still runs Python 3.3, and I'd like to use 3.3.0 (for the cache.lock(auto_renewal=True) convenience feature. But it seems I'll have to fork the project just to remove python_requires?

I'd love it if python_requires in future versions only excluded Python versions that definitely do not work (e.g. a critical wontfix bug has been reported), rather than versions that are EOL or that you no longer want to support.

ionelmc commented 4 years ago

I guess I could remove those constraints but that would just create pointless work for me - testing those versions is a huge pain cause pip doesn't support those versions anymore. If I'd leave those untested then I'd get bug reports about stuff being broken on something I don't care about, or PRs to add the constraints back :)

I suspect you may need to patch some things to get a working combination of old python + redis client, so a temporary fork doesn't sound that bad.

mrmachine commented 4 years ago

I have no problem with you not wanting to support an old/EOL version of Python. By all means, do not go out of your way to keep the project running on those versions. If you want to use a feature of a new/supported Python that is missing on old/EOL versions, then add the known incompatible version to python_requires. In that case, I'd have no issue creating a fork and making any required changes to get it working again.

Likewise, if you no longer tested or supported, and something accidentally broke and you got a non-trivial bug report, than close it as wontfix and add that version to python_requires.

But I generally don't see the point in prematurely disallowing your package to even be installed at all, as soon as an old version of Python itself is EOL, without any other known functional reason why it won't run. I think just like install_requires, packages that are libs and used by unknown 3rd party projects should be conservative and only exclude actual known incompatible dependency and Python versions.

I did previously use 3.3.0 with my project when it was running on Python 2.7, and it is now being upgraded to Python 3.3 (as a stepping stone, it's Django 1.6 which only supports up to 3.3). I did fork it and remove the constraint so I could get back to 3.3.0, and it seems to be working so far without any other modifications.