Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve debug logging for "Skipping wheel xxx-7.7.2-cp310-cp310-manylinux_2_35_x86_64.whl as this is not supported by the current environment" #9837

Open
alexanderilyin opened this issue Nov 8, 2024 · 7 comments
Labels
kind/feature Feature requests/implementations status/triage This issue needs to be triaged

Comments

@alexanderilyin
Copy link

Issue Kind

Change in current behaviour

Description

There is partcad package which depends on cadquery-ocp. Wheels for which are provided by:

And poetry ignores compatible wheel which has platform specified as manylinux

Give the following configuration:

[tool.poetry.dependencies]
cadquery-ocp = { version = "^7.7.2" }

poetry install will fail: output.txt.

When it's running on:

⬢ [Docker] ❯ python -c "import sys; print(sys.platform)"
linux
⬢ [Docker] ❯ lsb_release -d
Description:    Debian GNU/Linux 11 (bullseye)

According to the following:

cadquery_ocp-7.7.2-cp310-cp310-manylinux_2_35_x86_64.whl should be selected but in reality it's not supported by the current environment

Impact

It will allow to use Poetry with packages which are distributed for manylinux platform.

Workarounds

Override sys_platform using markers:

[tool.poetry.dependencies]
python = "^3.10"
partcad = { version = "^0.7.16", markers = "sys_platform == 'manylinux'" }
@alexanderilyin alexanderilyin added kind/feature Feature requests/implementations status/triage This issue needs to be triaged labels Nov 8, 2024
@alexanderilyin
Copy link
Author

Well, it's something else:

Package has cp310-cp310-manylinux_2_35_x86_64 tag but closest tag supported by Poetry is cp310-cp310-manylinux_2_31_x86_64.

Probably next step for me is to figure out what does 35 and 31 mean.

@alexanderilyin
Copy link
Author

Okay, it's actually 2_35 vs 2_31 which are glibc versions, and here is what I have:

⬢ [Docker] ❯ ldd --version
ldd (Debian GLIBC 2.31-13+deb11u11) 2.31

@alexanderilyin
Copy link
Author

It seems that in my case solution was to move from bullseye to bookworm:

⬢ [Docker] ❯ lsb_release -d
No LSB modules are available.
Description:    Debian GNU/Linux 12 (bookworm)
⬢ [Docker] ❯ ldd --version
ldd (Debian GLIBC 2.36-9+deb12u8) 2.36
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

@alexanderilyin
Copy link
Author

I'd keep this issue open but repurpose it to improve debug logging in is_supported_by_environment() so It would tell that my glibc is too old.

@alexanderilyin alexanderilyin changed the title Add support for "manylinux" platform Improve debug logging for "Skipping wheel xxx-7.7.2-cp310-cp310-manylinux_2_35_x86_64.whl as this is not supported by the current environment" Nov 8, 2024
@alexanderilyin
Copy link
Author

I think some kind of fuzzy search or levenshtein distance would allow to filter supported tag and then do some additional parsing / explanation.

@dimbleby
Copy link
Contributor

dimbleby commented Nov 8, 2024

code is here, if you have improvements to the logging please submit a merge request

though I'd hint that if you are getting into "fuzzy search or levenshtein distance" then you are likely over-complicating it

@alexanderilyin
Copy link
Author

Will do thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Feature requests/implementations status/triage This issue needs to be triaged
Projects
None yet
Development

No branches or pull requests

2 participants