I support the goal of making metadata match files as well. One alternative is have the ability to "yank" a package. Make it still available, but installable only when pinned explicitly. I believe that's what Rust does. -- M
On Dec 19, 2017 22:21, "Thomas Kluyver" <tho...@kluyver.me.uk> wrote: On Tue, Dec 19, 2017, at 9:10 PM, Matthias Bussonnier wrote: One case I could see is the use of the requires_python metadata. It was not included in the recent release of Django 2.0 (which is py 3 only) and making a new release will be useless as pip on py2 will still see Django 2.0.0 as Py 2 compatible download it and crash. Something similar happened to pytest - version 3.3 dropped support for Python 3.3 (the numbering is a coincidence, AFAIK). The requires-python metadata was set in the package, but the package was published via a devpi server, which didn't preserve that metadata correctly to send to PyPI. So now 'pip install pytest' on Python 3.3 downloads the new version and fails, rather than downloading an older, compatible version. The only way the project can fix this is to delete the releases with incorrect metadata. I support the larger goal of making metadata on PyPI match the metadata in the package, however. Thomas _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
