# Allowing Multiple Versions of Same Python Package in PYTHONPATH

**URL:** <https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219>\
**Category:** Packaging\
**Created:** [August 28, 2019, 2:22pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219 "2019-08-28T14:22:03Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![costrouc](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/costrouc/32/333_2.png) [@costrouc](https://discuss.python.org/u/costrouc)\
**Post date:** [August 28, 2019, 2:22pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/1 "2019-08-28T14:22:04Z")

</div>

TLDR; I wanted to get feedback on a potential feature that may be added to nixpkgs that allows multiple versions of the same python package to be installed in the same `PYTHONPATH`. This is a general approach that is not specific to nixpkgs and could be used in other package managers. The only nix specific part is the tooling to allow for the building of these specialized packages. All of the materials/demo is in this repo [https://github.com/costrouc/python-multiple-versions](https://github.com/costrouc/python-multiple-versions). Sorry discourse prevented sharing all links… to only 2 so go to the repo for actual html links. I want to clarify I definitely don’t think this is a feature that should be regularly used nor depended on. But for a package manager to provide a consistent place where all packages are “nearly” compatible a trick like this is needed for nixpkgs and possibly others.

# Demo of Multiple Python Versions

This is a self contained demo of having multiple versions of a python  
package in the same `PYTHONPATH`. In this demo `bizbaz` requires `flask=0.12.4` and `foobar` requires `flask>=1.0`. It requires nix (sorry no windows support in nix). This  
idea is not nix specific but would rely on package managers/builds to  
allow for multiple versions.

```auto
$ nix-shell
...
[nix-shell:~/p/python-multiple-versions]$ python
Python 3.7.4 (default, Jul 8 2019, 18:31:06) 
[GCC 7.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import foobar; foobar.foobar()
I am using flask version 1.0.3
>>> import bizbaz; bizbaz.bizbaz()
I am using flask version 0.12.4
>>> quit()
$ echo $PYTHONPATH
...:/nix/store/f3j11lk2m8ddw2j2axvcdfc2al2bk98c-flask-0.12.4/lib/python3.7/site-packages:.../nix/store/wv42si07c8wd64ravd4va4kh4j7prwlk-python3.7-Flask-1.0.3/lib/python3.7/site-packages:...

```

## Motivation

In nixpkgs we like to have a  
single version of each package (preferably latest) with all packages  
compatible with one another. Often times it is true that two packages  
may be incompatible with one another but if it is a compiled  
library/binary we have luxury of rewriting the shared library path  
allowing two packages that use different versions of a package to  
coexist. In python this philosophy breaks down because all packages  
are specified in the global `PYTHONPATH`. This means that if a package  
requires `import flask` it searches the path for flask and uses the  
one that it finds.

For nixpkgs this is troublesome because it prevents all packages from  
being compatible with one another.

### Examples of Issue

1. `jsonschema`. jupyterlab\_server  
requires `jsonschema >= 3.0.1` and `cfn-python-lint` did not  
support jsonschema 3 until about a month  
ago. 3.0 was released in February!

2. Some packages fix the version of a package such that other packages  
in the same PYTHONPATH cannot depend on the latest version. For  
example `apache-airflow` fixes pendulum ==  
1.4.4. That  
pendulum release is over 1.5 years old and libraries .io reports that 400+ packages depend on pendulum. We cannot let a single package restrict the version of other packages.

## How does this work?

I wrote a tool [python-rewrite-imports](https://github.com/nix-community/nixpkgs-pytools/#python-rewrite-imports) that helps to make multiple versions possible. Lets say that package `bizbaz` wants an old version of `flask==0.12.4` but we have another package `foobar` that requires the latest version of `flask>=1.0`. Normally these two packages would be incompatible. In order to do this we:

1. Create a build of `flask` for 0.12.4 and install
2. Use Rope to rewrite all the imports of flask of itself to `flask_0_12_4_1pamldmw2y7g` and rename the package to `flask_0_12_4_1pamldmw2y7g`
3. Rename the `dist` in site-packages and move the package to `flask_0_12_4_1pamldmw2y7g`
4. Rewrite all imports of `flask` in `bizbaz` to `flask_0_12_4_1pamldmw2y7g`

Rewriting all imports is done with Rope a robust python refactoring tool.

## Current Limitations

- Wanting several versions of a package that builds c-extensions  
looks a little hard than rewriting the imports?
- Suppose package A requires `C==1.0.0` and B requires  
`C>=1.1`. Let’s say that package B calls a method in A with a  
structure built from `C>=1.1` and then A proceeds to call its  
package C with that data. This will probably not happen often.
- Rope does not handle all rewrites currently in  
python 3. Expressions within `fstrings` are the only example that I  
know of.
- It is impossible for Rope to handle all import rewrites. For  
example. `import flask; globals()[chr(102) + 'lask']. __version__ `

I believe for the vast majority of packages that require multiple  
versions these issues will be rare.

---

<div class="post-metadata">

**Author:** ![costrouc](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/costrouc/32/333_2.png) [@costrouc](https://discuss.python.org/u/costrouc)\
**Post date:** [August 28, 2019, 2:23pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/2 "2019-08-28T14:23:50Z")

</div>

Links:

- [nixpkgs](https://github.com/NixOS/nixpkgs) a general package manager with 45k+ packages and 5k+ python packages.
- [Rope](https://github.com/python-rope/rope) python refactoring tool used in editors

---

<div class="post-metadata">

**Author:** ![FRidh](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/fridh/32/10749_2.png) [@FRidh](https://discuss.python.org/u/FRidh)\
**Post date:** [August 28, 2019, 3:01pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/3 "2019-08-28T15:01:52Z")

</div>

Crosslink to discussion at Nixpkgs Discourse [https://discourse.nixos.org/t/allowing-multiple-versions-of-python-package-in-pythonpath-nixpkgs/3849](https://discourse.nixos.org/t/allowing-multiple-versions-of-python-package-in-pythonpath-nixpkgs/3849)

---

<div class="post-metadata">

**Author:** ![FRidh](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/fridh/32/10749_2.png) [@FRidh](https://discuss.python.org/u/FRidh)\
**Post date:** [August 28, 2019, 3:06pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/4 "2019-08-28T15:06:22Z")

</div>

Situations that will need to be covered as well:

1. In a development environment where one works with plain Python as source, one needs to be able to perform an `import flask` instead of `import flask_0_12_4_1pamldmw2y7g`. I suppose shims are going to be needed that map to a certain hashed import.
2. Similarly, dynamic imports will resolve to something like `import flask` (as already mentioned in “Current limitations”).

---

<div class="post-metadata">

**Author:** ![njs](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/njs/32/204_2.png) [@njs](https://discuss.python.org/u/njs)\
**Post date:** [August 28, 2019, 7:57pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/5 "2019-08-28T19:57:28Z")

</div>

My worry is that this will cause tons of bugs to be filed on random packages because of subtle breakage you’re introducing, and package maintainers will have no idea what’s going on. All those “current limitations” are things that real packages do.

If you do this, please print some kind of banner at startup and in exception tracebacks noting that this is a nix-modified python setup and that any bugs should be reported to nix only.

---

<div class="post-metadata">

**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\
**Post date:** [August 28, 2019, 8:19pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/6 "2019-08-28T20:19:03Z")

</div>

Note that setuptools did something like this (but not nearly as invasive, as far as I know, as it didn’t have multiple versions of a package active at the same time), and even that has since been mostly abandoned as a bad idea (as I understand it).

I agree with @njs, this should be considered extremely non-standard, and very definitely “use at your own risk”. Package maintainers should not be expected to support this usage.

---

<div class="post-metadata">

**Author:** ![RonnyPfannschmidt](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ronnypfannschmidt/32/1714_2.png) [@RonnyPfannschmidt](https://discuss.python.org/u/RonnyPfannschmidt)\
**Post date:** [January 12, 2020, 4:33pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/8 "2020-01-12T16:33:13Z")

</div>

i consider it very worrying that instead of replacing/hooking ` __import__ ` module code gets actually changed

i recall a experiment with the import hook system enabling something comparable with import hook mechanism and ensuring the hook mechanism is correctly interjected

unfortunately i forgot the name of the experiment

---

<div class="post-metadata">

**Author:** ![uranusjr](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/uranusjr/32/103_2.png) [@uranusjr](https://discuss.python.org/u/uranusjr)\
**Post date:** [January 14, 2020, 2:07am UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/9 "2020-01-14T02:07:08Z")

</div>

> [@RonnyPfannschmidt](#):
>
> i recall a experiment with the import hook system enabling something comparable with import hook mechanism and ensuring the hook mechanism is correctly interjected
> 
> unfortunately i forgot the name of the experiment

I know Armin Ronacher wrote a POC before. Not sure if this is the same one as you have in mind (there are many similar experiments).

> **[GitHub - mitsuhiko/multiversion: A hack that allows you to use different...](https://github.com/mitsuhiko/multiversion)**
>
> A hack that allows you to use different versions of the same library in the same Python process without clashes - GitHub - mitsuhiko/multiversion: A hack that allows you to use different versions o...

---

<div class="post-metadata">

**Author:** ![RonnyPfannschmidt](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ronnypfannschmidt/32/1714_2.png) [@RonnyPfannschmidt](https://discuss.python.org/u/RonnyPfannschmidt)\
**Post date:** [April 6, 2020, 7:47am UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/10 "2020-04-06T07:47:48Z")

</div>

i refer to something one of the twisted developers experimented with, which could do multi version imports without code changes, however the changes to the import system where too invasive to have a future

---

<div class="post-metadata">

**Author:** ![bluebird75](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/bluebird75/32/2160_2.png) [@bluebird75](https://discuss.python.org/u/bluebird75)\
**Post date:** [November 26, 2021, 8:29am UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/11 "2021-11-26T08:29:59Z")

</div>

I was going to post something similar to python-ideas but just found this existing topic.

So, I had the same idea, but not related to nixpkg.

With the growth of the packaging ecosystem comes an increasing risk of dependencies version conflict.

I like Pip’s description of the problem: let’s say we have package _tea_ which depends on _boiling\_water_ v1.0 and _coffee_ which depends on _boiling\_water_ v2.0 . If I create package _afternoon\_drink_ which depends on both _coffee_ and _tea_, there is  
no correct version of _boiling\_water_ to use.

One solution could be side by side installation of different versions of the same package.

In practise, this could take the form of an additional directory similar to the site-packages directory. One could imagine a `versionned-packages` directory with the following content:

```
versionned-packages
	+ boiling_water
		+ v1.0/
			+ ...
		+ v2.0/
			+ ...

```

The files composing my initial example are:

**file boiling\_water.py (v1.0)**

```
class HotWater:
	pass

def heat_water():
	return HotWater()

```

**file boiling\_water.py (v2.0)**

```
# notice how v2.0 of boiling_water is incompatible with v1.0
class BoilingWater:
	pass

def boil_water():
	return BoilingWater()

```

**file tea.py**

```
import boiling_water

class Tea:
	def __init__ (hot_water):
		pass

def prepare_tea():
	# uses v1.0 of boiling_water
	hot_water = boiling_water.heat_water()
	tea = Tea(hot_water)
	return tea

```

**file coffee.py**

```
import boiling_water

class Coffee:
	def __init__ (boiling_water):
		pass

def prepare_coffee():
	# uses v2.0 of boiling_water
	boiling_water = boiling_water.boil_water()
	coffee = Coffee(boiling_water)
	return coffee

```

**file afternoon\_drink.py**

```
import tea
import coffee

def prepare_afternoon_drinks():
	my_tea = tea.prepare_tea()
	my_coffee = coffee.prepare_coffee()
	return [my_tea, my_coffee]		

```

The next step is to define how to import these versionned packages. I imagine something looking like this:

**file tea.py (with versionned packages)**

```
boiling_water = import_with_version('boiling_water', '1.0')

class Tea:
	def __init__ (hot_water):
		pass

def prepare_tea():
	# uses v1.0 of boiling_water
	hot_water = boiling_water.heat_water()
	tea = Tea(hot_water)
	return tea

```

**file coffee.py (with versionned packages)**

```
boiling_water = import_with_version('boiling_water', '2.0')

class Coffee:
	def __init__ (boiling_water):
		pass

def prepare_coffee():
	# uses v2.0 of boiling_water
	boiling_water = boiling_water.boil_water()
	coffee = Coffee(boiling_water)
	return coffee

```

The function import\_with\_version() would use the existing import machinery and add two functionalities:

- the imported module would be searched in `versionned_packages`, using the package name + version identifier instead of `site-packages`
- the resulting module would not be put into `sys.modules` but returned directly.

I believe this can solve the practical problem of conflicting package versions.

If I go one step further, one limitation of the solution above is the assumption that I can freely modify coffee.py and tea.py . Modifying dependencies is usually not  
possible nor desirable. A more evolved approach would probably look like this.

**file afternoon\_drink.py**

```
with ctx_import_with_version('boiling_water', '1.0'):
	import tea

with ctx_import_with_version('boiling_water', '2.0'):
	import coffee

def prepare_afternoon_drinks():
	my_tea = tea.prepare_tea()
	my_coffee = coffee.prepare_coffee()
	return [my_tea, my_coffee]		

```

The context manager `ctx_import_with_version()` would have to hook into the import  
machinery so that when `tea.py` performs its `import boiling_water`, it gets the v1.0  
version and `coffee.py` should get the v2.0 .

I am not that familiar with the Python import machinery, but from what I know, it does not look extra difficult. There are probably many edge cases which I am missing and which would require clever treatment but the general idea stands.

I am curious to know what other people think of this approach ?

Cheers,

Philippe

---

<div class="post-metadata">

**Author:** ![FFY00](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ffy00/32/4007_2.png) [@FFY00](https://discuss.python.org/u/FFY00)\
**Post date:** [November 26, 2021, 9:30am UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/12 "2021-11-26T09:30:22Z")

</div>

This can already be implemented using a 3rd party library, though I’d advise against it as it may lead to bugs when packages assume their are the only version and have global variables, etc

If you have a a very specific use case, this might be a reasonable thing to do, but it’s probably a footgun for general users, so I am not seeing this becoming a thing anytime soon.

---

<div class="post-metadata">

**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\
**Post date:** [November 26, 2021, 9:43am UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/13 "2021-11-26T09:43:15Z")

</div>

Agreed, and this was something that was in fact tried in the past, as part of the “egg” format introduced in early versions of setuptools. In general, the approach is considered to have failed, and it caused more issues than it solved.

If you’re interested in finding out more, I’d suggest researching how eggs and pkg\_resources did this. But like @FFY00 I’d be very surprised if there was any interest in this being a generally available feature.

---

<div class="post-metadata">

**Author:** ![bluebird75](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/bluebird75/32/2160_2.png) [@bluebird75](https://discuss.python.org/u/bluebird75)\
**Post date:** [December 4, 2021, 1:27pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/14 "2021-12-04T13:27:20Z")

</div>

Thanks for the feedback. The number of packages has increased quite a lot since the introduction of the egg format. I would expect the problem to be more prevalent today, so to have more users interested into a workaround.

I have no specific use case myself, but I am surprised not to see the solution being proposed a bit more. Package conflicts are a reality of today.

---

<div class="post-metadata">

**Author:** ![McSinyx](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mcsinyx/32/2107_2.png) [@McSinyx](https://discuss.python.org/u/McSinyx)\
**Post date:** [December 4, 2021, 1:55pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/15 "2021-12-04T13:55:23Z")

</div>

> [@bluebird75](#):
>
> Package conflicts are a reality of today.

I suppose a better solution is to encourage the upstream developers  
of conflicting packages to improve compatibility. In the worst case  
where compatibility cannot be achieved, an alias (e.g. pyreadline  
vs pyreadline3) can be created.

I don’t think downstream maintainers will be happy with multiple  
versions of a same package, plus single versioning makes it easier  
to roll out bug fixes for every package using an affected library.

---

<div class="post-metadata">

**Author:** ![takluyver](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/takluyver/32/513_2.png) [@takluyver](https://discuss.python.org/u/takluyver)\
**Post date:** [December 4, 2021, 4:24pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/16 "2021-12-04T16:24:59Z")

</div>

To explain a bit why this isn’t as desirable as it might seem: imagine I am using package A which imports NumPy 1.21, alongside package B which uses NumPy 1.16. I call `A.load_data()` which returns a NumPy array, then I pass it to `B.process(arr)`. Either B thinks it hasn’t got a NumPy array at all (`isinstance(arr, numpy.ndarray)` is False), or it has an array that may have a different layout than its NumPy library expects (different attribute & method names at the Python level, different memory layout at the C level).

Being restricted to a single version of a library actually makes life much simpler: within a process, you can assume that a NumPy array is a NumPy array, and you can always pass it back to NumPy functions. The alternatives would be that either the NumPy developers need to plan for in-memory forwards & backwards compatibility - handling an array created by both older & newer versions of NumPy - or that code using NumPy has to keep track of types like ‘NumPy 1.21 array’ and convert between different variants of the same thing.

I’m using NumPy as an example, but this would affect any library which defines its own classes and allows them to be used from outside its own code.

---

<div class="post-metadata">

**Author:** ![bluebird75](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/bluebird75/32/2160_2.png) [@bluebird75](https://discuss.python.org/u/bluebird75)\
**Post date:** [December 4, 2021, 9:30pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/17 "2021-12-04T21:30:32Z")

</div>

Your case makes sense but it’s the less common. The problem I described are sub-dependencies conflict. Being sub-dependencies, they are much more unlikely to be mixed together.

---

<div class="post-metadata">

**Author:** ![bluebird75](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/bluebird75/32/2160_2.png) [@bluebird75](https://discuss.python.org/u/bluebird75)\
**Post date:** [December 4, 2021, 9:42pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/18 "2021-12-04T21:42:00Z")

</div>

> [@McSinyx](#):
>
> I suppose a better solution is to encourage the upstream developers  
> of conflicting packages to improve compatibility.

In an ideal world, yes. In practice, many packages have no maintainer, that’s why they are likely to depend on an outdated version, which may eventually conflict with the latest version.

Look how many packages are still only python2 compatible.

> [@McSinyx](#):
>
> In the worst case  
> where compatibility cannot be achieved, an alias (e.g. pyreadline  
> vs pyreadline3) can be created.

You are assuming that the person haveing the problem has the control on one of its direct dependency and is able to patch it to rename a subdependency. That’s a significant effort and is simply not possible in many situatinots.

> [@McSinyx](#):
>
> I don’t think downstream maintainers will be happy with multiple  
> versions of a same package, plus single versioning makes it easier  
> to roll out bug fixes for every package using an affected library.

The problem exists, irrespective of whether it makes downstream maintainers happy or not. In the example I gave, you are faced with the following choices :

1. port package Tea to a new version of boiling\_water
2. port package Coffee to an old version of boiling\_water
3. give up because you have no porting effort capabilities
4. find a solution with multiversionning

Version 4 might be the only realistic and affordable solutions in many real-world situations.

---

<div class="post-metadata">

**Author:** ![sinoroc](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/sinoroc/32/1607_2.png) [@sinoroc](https://discuss.python.org/u/sinoroc)\
**Post date:** [December 4, 2021, 10:01pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/19 "2021-12-04T22:01:35Z")

</div>

> [@bluebird75](#):
>
> Being sub-dependencies, they are much more unlikely to be mixed together.

How so? I do not understand this statement.

---

<div class="post-metadata">

**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\
**Post date:** [December 4, 2021, 10:11pm UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/20 "2021-12-04T22:11:42Z")

</div>

> [@bluebird75](#):
>
> Version 4 might be the only realistic and affordable solutions in many real-world situations.

How is it more realistic and affordable to implement a whole new mechanism in Python, as opposed to upgrading a package to a newer version of its dependencies? Is it because you’re assuming that “someone else” would do the work in one case? The fact that you list “give up because you have no porting effort capabilities” suggests that you probably also don’t have the capability to implement multiversioning, so essentially you’re hoping that someone else will solve the problem for you.

I’d expect that the cost would be _far_ higher for (4), even if you allow for the fact that such a solution would only be implemented once whereas you might have to upgrade more than one package.

As I’ve already said, multiversioning solutions have already been tried and proved unworkable in practice. While someone might be willing to have another go at the problem, I’m pretty sure that things haven’t changed enough to alter the outcome. But if you (or anyone else) wants to try, no-one is going to stop you. Just don’t expect it to be easy…

---

<div class="post-metadata">

**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\
**Post date:** [December 5, 2021, 5:08am UTC](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219/21 "2021-12-05T05:08:45Z")

</div>

I hope you don’t feel as if your idea was immediately shot down. However, I think the issue here is you’re proposing a hypothetical solution to a hypothetical problem, without a substantial number of compelling real-world use cases that motivate the resources, complexity and risk the solution entails, in the face of a number of hypothetical and practical barriers to its implementation, and when there have been a number of real-world efforts to solve it over the years by some of Python’s most knowledgeable and experienced developers that have been uniformly unsuccessful and not merited sufficient real-world interest to sustain them.

> [@bluebird75](#):
>
> Your case makes sense but it’s the less common. The problem I described are sub-dependencies conflict. Being sub-dependencies, they are much more unlikely to be mixed together.

Particularly in the scientific Python ecosystem, at least from my experience as a user, developer and maintainer, I’d say its it’s much _more_ common than not that when two packages depend on one or more of the same packages deeper in the stack (Numpy, SciPy, Pandas, Matplotlib, Cython, Sympy, xarray, Dask, etc), there’s some form of direct or indirect data interchange, or other cross-dependency between at least one pair of them, if not most. In particular, when they are used, numpy arrays, pandas dataframes, xarray objects are routinely exchanged, and code compiled with different Cython versions (if they actually merited a hard dependency non-overlap) may well be ABI-incompatible and cause a C-level hard crash.

As such, it seems likely that this will further break as many packages as it will fix, and in ways that can be far harder to debug and recover from than a simple dependency conflict on installation, this does not really seem to be a viable solution, relative to other strategies. Of course, you’re always welcome to work on a proof of concept implementation, but I would suggest looking into real-world examples of conflicts affecting popular packages before investing too much time and effort into an approach that may or may not be useful to more than a niche handful of developers. Best of luck!

[Next page](https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219.md?page=2)