I HATE PYTHON [LWN.net]

I HATE PYTHON

Posted May 24, 2025 0:14 UTC (Sat) by himi (subscriber, #340)
In reply to: I HATE PYTHON by geofft
Parent article: Recent disruptive changes from Setuptools

I've run into issues with uv's managed python installs, specifically with the netaddr package - which is an unmaintained beast of a thing, admittedly, but also a common enough requirement (particularly in the OpenStack context, where I work) that I didn't have much choice. In the end I just went with the system python and the distro's python3-netaddr package, because I couldn't find a way to get the managed python install to successfully build netaddr from source (netaddr's fault, not uv's), or provide some way to inject my own build into the environment.

Unfortunately, I don't have notes about what exactly I did, and it was on my previous machine so it's rather hard to go back and re-run things to give a proper bug report, or see if things have changed in the ~6 months since then (a distinct possibility given how fast uv has been evolving) . . .

I'd like to say that fixing the issue of unmaintained or badly maintained packages isn't something that the Python packaging community should be responsible for . . . and it really isn't . . . but there are degrees of failure, some more graceful than others, and it felt like I was hitting a brick wall rather than something more accommodating. Obviously a managed python install is a very curated and controlled environment and there's a limit to the degree of flexibility that you can provide, but that can make them unusable sometimes, particularly when it comes to oddball cases like netaddr.

I HATE PYTHON

Posted May 24, 2025 1:10 UTC (Sat) by geofft (subscriber, #59789) [Link] (1 responses)

Er, are you sure you're thinking about netaddr? That's a super straightforward pure Python package and so building it should be trivial, but also it has platform-independent wheels so you don't even need to do that.

For completeness, I just checked `uv run --with netaddr python`, and then pinned to various recent and not-so-recent versions, including the versions packaged in Debian stable/oldstable which are well older than uv itself. I also tried with `--no-binary` to force a local build. All seemed to work fine.

(Looking around Debian for similar-sound arch-dependent packages... did you mean netifaces? That one has compiled code and a pretty dusty build system, but it does seem to work fine with uv, too. I did get a failure the first time I tried because I didn't have a C compiler on my PATH, and I got a failure the second time because netifaces caches its configure-esque checks and uv leaves that around, but it works if you blow that away and retry.)

Regarding old versions, I actually think that's a reasonable expectation, provided that the actual code is -compatible with your current Python version. Sometimes you might need to do things like pin an older setuptools in the build environment (to get back to the subject of the article), and maybe that process needs better docs and error messages, but it's the sort of thing that should be doable.

I HATE PYTHON

Posted May 24, 2025 1:54 UTC (Sat) by himi (subscriber, #340) [Link]

Yes, insufficient caffeine on a lazy Saturday morning caused me to confuse netaddr for the real culprit, netifaces. If it's working now that may well be due to changes since I ran into this issue - uv development is almost as fast as its runtime, it can be hard to keep up. It may also have been using a more modern Python version than netifaces wanted? I honestly can't recall the details, and I'd have to do a lot of work to rebuild enough context to try and replicate the issues.

One of the things that would have been useful, I think, would be a way to use the system python's packages to resolve certain dependencies - possibly by importing them into the managed python install, or into the venvs that uv builds. Obviously assuming you're working with sufficiently compatible versions (which may well be hard to figure out) . . . It's not going to be something you want to use regularly, and it'd need to be explicitly chosen per-package, but it might be useful if the problem packages are a ways down the dependency tree and unresolvable otherwise.

I HATE PYTHON

Posted May 24, 2025 1:15 UTC (Sat) by himi (subscriber, #340) [Link]

ugh . . . I am, apparently, an idiot when I haven't had enough coffee - the package I was having issues with was netifaces, not netaddr. Definitely a case where editing comments would be useful, if only to minimise my embarrassment . . .