Getting rid of virtual environments with a better dependency system

[j c]

On Wednesday, 11 November 2020 at 12:22:24 UTC+1, Chris Angelico wrote:
> On Wed, Nov 11, 2020 at 10:06 PM j c wrote: 
> > 
> > Hello all, 
> > 
> > I don't know if this suggestion is missing some point, or it's part of something already proposed. 
> > 
> > In a professional environment, we've came to a point in which most people use virtual environments or conda environments to avoid "polluting a global environment". 
> > 
> > However, I think that's a problem with the default behaviour of the module management in Python. A nice default behaviour would be to search for a requirements.txt file in the same directory as __file__, and use the newest version of every module that matches the constraints. If no requirements where given, the newest version already installed could be used. That would require allowing multiple versions of the same module to be downloaded. 
> >
> This would stop venvs from providing the isolation that they are 
> supposed to, and instead would just create yet another way to invoke 
> dependency hell. No thank you. 
> 
> A virtual environment isn't just a way to install different versions 
> of modules. It's way WAY more than that, and if you need to have too 
> many different versions around, you have bigger problems to deal with. 
> 
> (As a simple thought experiment to prove the problem with your 
> proposal: what happens with your dependencies' dependencies, and what 
> if they conflict? At what point would that be detected?) 
> 
> ChrisA

How can this behaviour turn into dependency hell? Every dependency use the specified version if any, otherwise the most recent one, which also applies to second order dependencies. In case of conflict, the first version would be imported, which is currently the default behaviour. The main difference is that this approach would be able to generate a warning before running the script with no need for pipdeptree.