Open alexis-girard opened 1 year ago
You should put the same metadata in all distributions and use markers for eg python-version-specific variations.
You should put the same metadata in all distributions and use markers for eg python-version-specific variations.
It's incorrect behavior, all packages have different metadata. Package for py3.6 requires numpy between 1.17 and 1.20 but py3.10 package requires nump >= 1.22
Having the same metadata for all packages and a custom marker to differentiate them seems bad practice. Or am I misunderstanding the whole point ?
Also good to note that pip can successfully determine the right package, no matter which python version is used.
It's incorrect behavior, all packages have different metadata.
In our opinion that's bad practice. Poetry does not support this for practical reasons (complexity, performance).
Having the same metadata for all packages and a custom marker to differentiate them seems bad practice. Or am I misunderstanding the whole point ?
It's not bad practice, it's state of the art and defined in PEP 508.
Isn't "install_requires" writing environment markers ?
The fact is, numpy is a strong reference for this library, the generated library specify the version requirements when generating the package using
install_requires(numpy >= MIN_VERSION, < MAX_VERSION)
How can I have the same metadata for all the packages and just write environment markers to specify the numpy versions ? I think I miss something there, I'm not super familiar with python.
It depends on the build-backend you use to build your library. For example with setuptools: https://setuptools.pypa.io/en/latest/userguide/dependency_management.html#platform-specific-dependencies
Discussed in https://github.com/orgs/python-poetry/discussions/8531
Hi, I'm opening a ticket on this as it seems like an issue to me and it remains unanswered on Q&A. Basically when having multiple packages in a pip repository targeting different python versions, the first package is assumed to have metadata consistent with the rest of the packages.
Which is obviously false as packages' support for python versions evolves with time.
Any help is appreciated ! Do you think an algorithm extracting metadata from a wheel compatible with the python version used by the current poetry env would be a good thing ? This solution seems more compliant with PEP 658 than the current one.
Thanks for your help, Best, Alexis.