Hacker News Reader

Comment by jimjag | Hacker News Reader

This has the same issue as so many package managers for Python, namely, it doesn't provide a way for --no-binary to remain sticky.

There are times when you do NOT want the wheel version to be installed (which is what --no-binary implements in pip), but so many package managers including uv don't provide that core, basic functionality. At least for those that do use pip behind the scenes, like pipenv, one can still use the PIP_NO_BINARY environment variable to ensure this.

So I'll not be migrating any time soon.

View on HN

Maybe not exactly what you need (sticky) but you can set UV_NO_BINARY=1

See https://docs.astral.sh/uv/reference/environment/#uv_no_binar...

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.

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?

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

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.

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.

> So your question effectively boils down to "why do people need to compile their own software?".

No, the question is why a package would need to decide for its users that the package and its dependencies must be installed the gentoo way. That's quite obviously different from why an end user would decide to install from source despite the availability of binary packages.

> There are times when you do NOT want the wheel version to be installed

When, why? Should I be doing this?

There are some wheels, for example, 'lxml' that bundle in their binary possibly incompatible external libraries, or older libraries than what you would like. This can cause library conflicts.

Reply on news.ycombinator.com