Poetry is taking first wheel metadata only and thus fails to find package

[alexis-girard]

• [x] I am on the latest stable Poetry version, installed using a recommended method.
• [x] I have searched the issues of this repo and believe that this is not a duplicate.
• [x] I have consulted the FAQ and blog for any relevant entries or release notes.

Discussed in https://github.com/orgs/python-poetry/discussions/8531

^{Originally posted by **alexis-girard** October 12, 2023} Hi everyone, I didn't know where I should be posting this question, we have a python library packaged and uploaded on an internal repository (Artifactory). This library is built for a range of Python 3.6-3.10 and is based on numpy. As you may know, numpy compatibility is dependant of Python version. For example, python 3.6 is compatible with this range of numpy 1.17.0 - 1.20.0 while python 3.10 is compatible with numpy >= 1.22 With poetry using the first wheel it finds to extract the metadata, it fails to find the package version compatible with Python 3.6/numpy 1.17 Here is an example : ``` [tool.poetry.dependencies] python = "3.6.8" numpy = "1.17.0" my-package= "1.0.0" ``` Here is my poetry env info ``` Virtualenv Python: 3.6.8 Implementation: CPython Path: ... Executable: ... Valid: True System Platform: win32 OS: nt Python: 3.6.8 Path: C:\Python\3.6.8 Executable: C:\Python\3.6.8\python.exe ``` The first package in the list is the package for Python 3.10 and poetry reports a version solving failed due to numpy requirement not satisfied. Am I not using correctly ? How am I supposed to handle this, any suggestions are welcome. Best, Alexis.

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.

[dimbleby]

You should put the same metadata in all distributions and use markers for eg python-version-specific variations.

[alexis-girard]

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.

[radoering]

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.

[alexis-girard]

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.

[radoering]

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