Missing wheels for recent versions break some dependencies.

[orioltinto]

What happened?

The latest releases of eckit, eccodeslib, and eccodes on PyPI only provide macOS wheels.

This makes installation difficult on Linux (and other platforms) when using modern package managers such as uv, which rely on prebuilt wheels for reproducible installs.

What are the steps to reproduce the bug?

uv add eccodes

Version

1.32.1.2

Platform (OS and architecture)

Anything which is not mac, I guess

Relevant log output

error: Distribution `eckitlib==1.32.1.2 @ registry+https://pypi.org/simple` can't be installed because it doesn't have a source distribution or wheel for the current platform

Accompanying data

No response

Organisation

No response

[tmi]

hello @orioltinto , please see this issue ecmwf/eccodes#370 for explanation of this change, and possible mitigation -- ie, its not missing, its just independently versioned across platforms

[tmi]

I see that indeed uv add eccodes fails, but then I also get uv add numpy fail with

  ╰─▶ distutils was removed from the standard library in Python 3.12. Consider adding a constraint (like `numpy >1.24.4`) to avoid building a version of numpy that depends on distutils.

as well as uv add numpy>=2.0.0 failing with

  ╰─▶ Because the requested Python version (>=3.8) does not satisfy Python>=3.11 and the requested Python version (>=3.8) does not satisfy Python>=3.10,<3.11, we can conclude that Python>=3.10
      is incompatible.

where obviously the project works with numpy. So uv add is rather heavy handed. But regular uv pip install eccodes works fine

[orioltinto]

I can't reproduce your problem with numpy, it works without problems in my case. And I bet that it is the case for most people since it is used "everywhere".

[tmi]

I can't reproduce your problem with numpy, it works without problems in my case. And I bet that it is the case for most people since it is used "everywhere".

presumably because you have tighter bounds on python versions on platforms. The problem with uv add is that it tries to find one single version that works across all python version and all platforms that your pyproject allows -- which is great in many cases, eg all pure python packages. But with binary wheels less so. For example imagine you want jax[cuda] on linux but jax[mps] on macos -- you can't really add that with uv add jax.

saying that uv add eccodes should work everywhere would force us to keep releases for all platforms and for all python versions in a tight sync -- which we are not going to commit to. For example we have not released python 3.14 yet.

what works is to let uv know that those packages are binary and platform dependent, in the following fashion:

uv add 'eccodes; os_name=="darwin"' 'eccodes; os_name=="linux"'

[orioltinto]

In my case it tries to make it run on Linux, and only the Mac wheels are available.
To be honest, it is confusing to me that only mac wheels are available, but I guess that there must be a reason for that.

The proposed solution does not return an error but does not end with the library properly installed.
There are possible workarounds (like uv pip install), but the main issue is that then we can not properly use uv (or poetry it seems) with anything that depends on eccodes, which is inconvenient.

It is not a blocking bug, but if it matters it would be nice if at some point this does work.

Thanks for your time.

[tmi]

The proposed solution does not return an error but does not end with the library properly installed.

how come? When I run it, I end up with

dependencies = [
    "eccodes>=2.44.0 ; os_name == 'darwin'",
    "eccodes>=2.44.0 ; os_name == 'linux'",
]

which looks good to me... What do you end up with, and why do you think it doesn't work? (Ftr, I can also manually just add dependencies = [ "eccodes" ] which has the same net effect... ie the discriminator is not really needed for the toml to be legit)

we can not properly use uv

you mean using uv pip install is less proper than uv add? Or uv add with os discrimanators is improper? Why?

[orioltinto]

I end up with the same thing in the pyproj but after uv sync these dependencies are not installed.

Adding this to the project did change the behavior, though:

[tool.uv]
environments = ["sys_platform == 'linux'"]

I guess that it is related to what you were mentioning before about the platforms.

[tmi]

ah ok, not familiar with uv sync enough -- I tested only via uv pip install -e . Pretty odd that it doesn't pick the environment automatically... that said, I tested your command, and no amount/combination of uv lock, uv sync --all-packages, uv sync --locked, etc, installed into .venv... no idea why. I would guess its the same like activating the .venv and uv pip installing into that from the lock, right? But that sequence does work, in particular, the uv.lock file it generates is correct