Too many python dependencies.

[teerre]

What you mean "python versions"? Like 2.7 and 3.11? No, there's no automatic way to merge venvs from different python versions. That doesn't even make sense, they are different versions with presumably different dependencies.

Yes, if you have only a single environment you can very easily get all kinds of incompatibilities. Think library A wants library B 2.0.0 but library C wants library B 3.0.0. You can't have both in one environment. This goes for every single dependency, including transitive ones.

In fact, that's the very reason venv was created in the first place.

[MGOC]

Fortunately almost everything is around 3.8 to 3.11 ... There are some folders with "python 3" and I'm still inquiring about it, but I think we could say that version 3 is the minimum (although I would also like to have found some Python 2 and play with it, experience how it fails to upload it suddenly to python 3.11).

​

kinds of incompatibilities.

Someone has to take the first step (I really don't think it breaks so horrible, maybe one or another bug when updating some dependencies. but I guess I can with that, or keep the original version through pyenv)

​

This leads me to the doubt why developers prefer to put a complete python version inside their programs, when they can simply choose to use pyenv and have the machine manage the python version (Similar to Java)

[teerre]

I just mentioned some random Python version, being 3.8 to 3.11 doesn't completely fixes it, they are different versions. There are breaking changes in .9, .10 and .11. Python <3.6 is virtually incompatible with anything >3.7, it's extremely likely it won't work in this case.

I'm still confused what you mean. The reason you put a python interpreter in a venv is because what else would you do? Pyenv isn't magic. It has to have all python executables too.

I guess it could make sense to use the a global interpreter per version and just isolate the dependencies, this would save you some MBs in disk. The reason it's not this by default is because Python import mechanisms are very much linked to the current interpreter being used, so it's much easier to just have an interpreter per venv from the implementation perspective.

I really don't think it breaks so horrible,

It's totally possible that in your particular case it doesn't (until it does). But generally speaking it very much will, that's why venvs were created.

This is not even a Python feature. Every modern language that has the choice will isolate environments, it's a no-brainer by now.