PEP 704 – Require virtual environments by default for package installers | Hacker News Reader

PEP 704 – Require virtual environments by default for package installers

peps.python.org

I can't see this being accepted even though I think standardisation is the way to go, because there's a signficant amount of diversity for 'virtual environments' in Python with:

* virtualenv (external library)

* venv (fork of virtualenv included in standard library from 3.3 onwards)

* conda

* poetry

* pipenv

All I’m seeing here as a Python outsider is a whole lot of duplicated work and confusion. There should be more or less just one way to do virtual environments that will work with everything.

In over 20 years of using Python for large and small projects and one-off scripts I have never not even once needed a virtual environment. That is not to say that virtual environments are useless in general, but for me they are. Python's great strength is that it is flexible and adapts to your workflow rather than forcing you into its preferred workflow like some other language (f.e. Scala and Clojure). For many users, all this change would entail would be lots of duplicated .venv directories filled with NumPy, Pandas, TensorFlow, matplotlib, etc. installations littering their hard drives. Also hidden dot directories were a horrible idea 60 years ago and it still is.

> Python's great strength is that it is flexible and adapts to your workflow rather than forcing you into its preferred workflow

This kind of 'flexibility' has been Python's downfall in package management, which is an area widely (and rightly, imo) regarded as a disaster for Python.

That said, I'm not convinced this proposal has the right idea, either. It has the same smell as Docker: just take all the same complexity and shove it into a shiny new box, then start passing whole boxes around!

I've honestly never felt that package management is particularly difficult in Python. If you want a language where package management is a real clusterfuck try Haskell or Scala.

The thing that's a biggest pain IME in Scala (evictions due to mismatched transitive dependency versions) is also a problem in Python, because only one version of a library can be loaded into a single Python process.

What are your other pain points with Scala packaging?

Reply on news.ycombinator.com