News for hackers. Stuff that matters.
Re:Uv is fantastic, but its package management UX is a mess by kibwen on Thursday May 21, 2026 @08:21PM (#48230426)
The use or adherence to semver isn't the problem here. As you say, if a package follows semver, it's easy enough for the package managers to automatically update to newer compatible versions. The problem is when you want to have two different incompatible versions of the same package `foo` in the same program, because then you have to figure out what `import foo` means. You might say "just don't do that", but that package could be an indirect dependency of several of your direct dependencies. Some languages handle this natively, e.g. in Rust it just works if you have multiple versions of the same library in different parts of your dependency tree (and you'll get a compilation error if you try to pass a type from one version into a function of an incompatible version). But Python does not handle this use case very well.
Re:Uv is fantastic, but its package management UX is a mess by skeledrew on Thursday May 21, 2026 @09:35PM (#48230932)
> Python does not handle this use case very well

I solved this issue a few months ago. Created a tool that essentially allows the use of multiple envs at once, with their own versions of packages at any level.

Re:Uv is fantastic, but its package management UX is a mess by mroche on Friday May 22, 2026 @01:06AM (#48232193)
This sounds... not possible for the core problem of how Python handles dependency resolution during the life of an application? How are you setting things up so that the following scenario is valid?

    program
    ├── dependency_a
    │   └── dependency_c (1.0.0)
    └── dependency_b
        └── dependency_c (2.0.0)
Otherwise, you've created a magic layer hack to enable multi-version dependency chains in a mono-version dependency chain language.
Re:Uv is fantastic, but its package management UX is a mess by yorwba on Friday May 22, 2026 @04:42AM (#48233454)
Python's import system is extensible: https://docs.python.org/3/reference/import.html#import-hooks It might be possible to create a custom finder that will return 1.0.0 when running "import dependency_c" in dependency_a but 2.0.0 for the same import statement in dependency_b. You'll need to work around the module cache in sys.modules, though. And good luck trying this on a package that also hooks the import system...
Re:Uv is fantastic, but its package management UX is a mess by skeledrew on Monday May 25, 2026 @12:15AM (#48263340)
Yep that's pretty much how I do it, along with RPyC[0] for connection.

[0] https://rpyc.readthedocs.io/en/latest/

Re:Uv is fantastic, but its package management UX is a mess by skeledrew on Monday May 25, 2026 @12:17AM (#48263352)
I'll try to get around to a Show HN some time for it, but it's essentially as sibling reply states.
Re:Uv is fantastic, but its package management UX is a mess by arcatek on Friday May 22, 2026 @03:00AM (#48232877)
Curious how you did this; I looked into that couple of months ago but even with custom hooks the Python injection points seemed to limited due to the internal resolution cache.
Re:Uv is fantastic, but its package management UX is a mess by skeledrew on Monday May 25, 2026 @12:13AM (#48263331)
Its just objects accessed via RPyC[0] and exposed with import hooks. Thinking of a Show HN but there repo isn't really publish-ready.

[0] https://rpyc.readthedocs.io/en/latest/

Re:Uv is fantastic, but its package management UX is a mess by __mharrison__ on Thursday May 21, 2026 @10:24PM (#48231245)
I'm curious. Do you have real world examples of when you want to do this?
Re:Uv is fantastic, but its package management UX is a mess by gbear605 on Thursday May 21, 2026 @11:07PM (#48231513)
This is Java, but recently I had a case where one library depended on a version of an Apache Commons library, and another library depended on a different version of the same Apache Commons library, and neither version worked with both libraries. In my case, I was able to upgrade one of them to a newer version so that I could use just one Apache Commons version, but I got lucky there.
Re:Uv is fantastic, but its package management UX is a mess by deathanatos on Friday May 22, 2026 @12:22AM (#48231892)
The monolith I work on has this dependency chain:

  monolith -> openai
  monolith -> langchain-openai -> openai
openai, thus, is both a direct and indirect dependency. langchain-openai recently had a vulnerability, and the patch fix is only after a major upgrade to openai. Thus, to upgrade langchain-openai here, I also need to upgrade monolith's use of openai. (From v1 to v2.)