The 2.3.1 release dropped support for Python 2 but the release on PyPI is still marked as supporting Python 2. Naively installing the package with pip install python-daemon in a Python 2 environment results in a package that cannot be used. A python_requires=">=3" or similar should be added to setup_kwargs in setup.py to prevent this issue.
2.3.1
pip install python-daemon
python_requires=">=3"
setup_kwargs
setup.py
It would be great, but I'm not sure how much appetite the maintainers have, to pull the 2.3.1 release on PyPI and cut a new release (I'm of the mind that dropping support for a version of Python should not be included in a patch release) that correctly reflects the Python 3 only status of the code base.
Howdy @mcdonnnj:
Naively installing the package with pip install python-daemon in a Python 2 environment results in a package that cannot be used. A python_requires=">=3" or similar should be added to setup_kwargs in setup.py to prevent this issue.
The current trove classifiers do not include "Programming Language :: Python :: 2" (and only include "Programming Language :: Python :: 3"), so any tool installing to Python 2 should be aware of that declaration. Why are Python installation tools ignoring that declaration?
Yes, I'm willing to do that (as you say, a PyPI package that fails to install correctly, should not be the latest available for Python 2 at PyPI). First though I'll need to understand what installation tools are misunderstanding the metadata.
Hey @bignose:
Thanks for the reply! So the trove classifiers are used to filter projects on PyPI and are not used by clients such as pip that consume Python packages (to my knowledge). Those clients follow the Metadata 1.2+ standard which expects a Requires-Python entry to control Python version restrictions. The best source for updating your package is the official packaging guide which details options for how to go about dropping support for older Python versions.
pip
Requires-Python
I created #67 based on the above mentioned documentation.
Thank you for the explanation and implementation. I have now "yanked" version 2.3.1 from PyPI so that it no longer is offered as an installation candidate; and released version 2.3.2 to correct this issue.
Metadata Update from @bignose: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)