Python environments let different projects use incompatible versions of the same library, but remembering to activate the correct environment can be confusing. Why doesn't Python instead use a Flatpak-like approach: reuse an already-installed dependency when its version is compatible, and install another version alongside it when necessary? Would this be technically feasible, or would the result create more problems than it solves?
4 Answers
Rust uses a similar general idea, allowing different dependency versions in one project, and it can produce confusing errors such as expecting a type from one version but receiving a seemingly identical type from another. Modern tooling gives better diagnostic information, but the underlying complexity is still there. Python could theoretically support more automatic dependency coexisting, but every package would need to handle which version it imports, and many libraries are not designed for that.
Some ecosystems try this by allowing each package to carry its own dependency versions. The trouble is that two versions of the same library can both be loaded into one process, and they may produce objects that look identical but are not interchangeable. For example, library A might return an object created by version 1 of library C, while library B expects an object from version 2. The names and APIs can match, but the runtime treats them as different types, which can lead to subtle failures.
That makes sense. I was thinking of dependency reuse mainly as a convenience, but I can see how having multiple copies loaded at once could make object and type compatibility much harder.
Flatpak solves a somewhat different problem. A Flatpak application is usually isolated from the rest of the system and runs with a specific runtime, so its dependencies do not normally have to interact with dependencies from another application. Python packages often interact directly inside the same process, pass objects between one another, register plugins, and share global state. That makes side-by-side versions much riskier.
So Flatpak can keep applications apart, while Python would be trying to combine potentially conflicting libraries inside one application. That explains why the comparison is not quite equivalent.
The main benefit would be convenience: one global installation where you do not have to remember which environment is active. The downside is reproducibility. Separate environments make a project’s complete dependency set explicit, prevent one project from breaking another, and make deployment easier to reproduce. Tools can improve the workflow by creating or selecting environments automatically, but removing isolation would trade a visible inconvenience for harder-to-diagnose failures.
The clearer error messages definitely help, but it sounds like they do not eliminate the fundamental issue that two versions of a package are separate identities.