Deno-like imports/installs in Python

Hello,
I built depfix to address one big pain in Python: dependency conflicts.

Normally, if two packages require different versions of the same dependency, you need separate environments or you have to change one of the packages. Python’s import system assumes one active version of a module per process.

Depfix works around this by resolving packages into separate dependency realms and loading them under isolated module identities.

Use like:

import depfix
with depfix.using("requests==2.31.0"):
    import requests as requests_old
with depfix.using("requests==2.32.3"):
    import requests as requests_new

Both versions can exist in the same process, and each package keeps using the dependency versions from its own graph.

Depfix uses uv internally for resolving and downloading packages at runtime into separate realms. It works sort of like DenoJS imports.

Repo:

It is still experimental. Pure-Python packages are the main target right now, while native extensions have stricter limitations.

I’m looking for feedback on the import architecture and examples of dependency graphs or package behavior that are likely to break it.

Thanks, Jan.

Is there an (ideally non-LLM) short descriptions of how this works?

Frankly, I think dynamic/imperative dependencies are a bad thing and shouldn’t exist so definitely not something I’ll advocate for.

The main issue that breaks this kind of resolution with multiple versions of libraries loaded in the same process is that they sooner or later expects and returns data structures that differ between those library versions.

This often works in “most” cases since thoose structure rarely change but once they do it will generally result in very hard to diagnose bugs when invariants between those versions are violated.

Most libraries expects all objects they handle of classes they define to only be created by that same version of the library.

That’s a good call, thank you. I’ll try to find some and run some tests on them.