[jimjag]

It helps, that's for sure. But this sort of knowledge should not exist in the environment in any case. It should be part of the canonical package list, and not hidden away elsewhere. The whole idea of a dependency manager should be a centralized and consistent way to install everything you need and not be dependent on what values may or may not exist as a env-var.

[wtallis]

Can you elaborate on the reasons why a package would need to declare that its dependencies must be installed from source rather than from pre-built binaries? I'm having trouble imagining a scenario where that capability would be used as anything other than a workaround for a deeper problem with how your dependencies are packaged.

[perrygeo]

Let's say you're developing a python package that relies on a native shared library. If you distribute it as a pre-compiled wheel, you're locking your users into the exact version and compilation flags, options, etc that you choose. So your question effectively boils down to "why do people need to compile their own software?".

Many reasons: you need more control, specialized hardware, testing newer versions of the library, maintaining an internal fork of a library, security, performance, the dev team maintains both the native library and python package and needs to keep them independent, or simply preference for dynamic linking against system libraries to avoid duplication.

[csl]

Yes, I can see how it would make sense to be able to set this in pyproject.toml (typically for private package)

uv is still quite new though. Perhaps you can open an issue and ask for that?

[collinmanderson]

It looks like there's already a pyproject.toml no-binary option?

   [tool.uv]
   no-binary = true

Or for a specific package:

    [tool.uv]
    no-binary-package = ["ruff"]

https://docs.astral.sh/uv/reference/settings/#no-binary