How Python virtual environments work

That's insightful.

It seems that a virtual environment created by Poetry looks very similar, except that it doesn't contain an `include` directory. It contains:

* `bin` directory

* `lib//site-packages/` directory

* `pyvenv.cfg`

This writeup needs work.

> So while you could install everything into the same directory as your own code (which you did, and thus didn't use src directory layouts for simplicity), there wasn't a way to install different wheels for each Python interpreter you had on your machine so you could have multiple environments per project (I'm glossing over the fact that back in my the day you also didn't have wheels or editable installs).

This is a single run-on sentence. Someone reading this, probably doesn't know what "wheels" means. If you are going to discount it anyway, why bring it up?

> Enter virtual environments. Suddenly you had a way to install projects as a group that was tied to a specific Python interpreter

I thought we were talking about dependencies? So is it just the interpreter or both or is there a typo?

> conda environments

I have no idea what those are. Do I care? Since the author is making a subtle distinction, reading about them might get me confused, so I've encountered another thing to skip over.

> As a running example, I'm going to assume you ran the command py -m venv --without-pip .venv in some directory on a Unix-based OS (you can substitute py with whatever Python interpreter you want

Wat? I don't know what venvs are. Can you maybe expand without throwing multi-arg commands at me? Maybe add this as a reference note, rather than inlining it into the information. Another thing to skip over.

> For simplicity I'm going to focus on the Unix case and not cover Windows in depth.

Don't cover Windows at all. Make a promise to maintain a separate doc in the future and get this one right first.

> (i.e. within .venv):

This is where you start. A virtual environment is a directory, with a purpose, which is baked into the ecosystem. Layout the purpose. Map the structure to those purposes. Dive into exceptional cases. Talk about how to create it and use it in a project. Talk about integrations and how these help speed up development.

I also skipped the plug for the mircoenv project, at the end with a reference to VSCode.

Depends if any of your packages use absolute paths (generated at install time for example).

Answer: they don’t

(Seriously, I’ve gotten so fed up with Python package management that I just use CondaPkg.jl, which uses Julia’s package manager to take care of Python packages. It is just so much cleaner and easier to use than anything in Python.)

also there's like 3 different flavors of virtual env now and me being 8 years out of date with my python skillz i have no idea what the current SOTA is with python venv tooling :/

i dont need them demystified, i need someone smarter than me to just tell me what to do lol