Regels! Regels! Belgen willen meer regels. Baas! Baas! Leg mij meer regels op.

Some use-cases:

1) applying monkeypates to third-party executables

2) read .env-file at startup to your env-vars are automatically available in python/ipython-repl, notebooks, any python-based executable in your venv

3) Add bin-directory of your venv to your PATH without the need to activate.

sitecustomize.py

I use it in *every* project since 8 years.
Since last year I switched to a plugin-architecture using entrypoints.
see pypi.org/project/site...
More plugins at github.com/libranet

As an example, I install the virtualenv-package in its own virtualenv and configure it via "make install"
github.com/libranet/lib...

I always configure venv-based tools to never write to $HOME
I turn every (non-dev) venv into an isolated application directory. And it works great.

It then becomes a nuisance to be forced to have an extra sub-directory that I need to workaround via 3 extra symlinks:

bin/ -> .venv/bin/
etc/
lib/ -> .venv/lib/
.env
.venv
pyvenv.cfg -> .venv/pyvenv.cfg
var/cache
var/log
var/tmp

I have +100 python-based tools on my laptop, each in their own directory. venvs are nice, but for me as a power-user and my deployments, they are not enough.
Every venv I create has it own temporary directory and cache-directory at minimum:

bin/
etc/
lib/
.env
pyvenv.cfg
var/cache
var/log
var/tmp

As a power-user *I* want to manage deployment of the application-directory, which is a superset of pip-installing packages.
I don't see a problem with having some bash-scripts in a bin-subdirectory and commiting these to the repo,
and have a script to turn this folder into a virtualenv.

With uv having the momentum,
but also uv cannibalizing the hardcoded .venv-directory,
I'm afraid this will be the new de facto standard. And this will remove various use-cases I've seen in the wild, esp corporate settings. The /usr/local being one example.

A tool deleting files not managed by that tool, without warning or asking user-confirmation. That is at least not wanted behaviour.

"Virtualenv" or "python -m venv" do not have that behaviour.

I currently work in a company that standardized on pip installing in
VIRTUAL_ENV=/usr/local

Not my choice, it works, and I can't change it for the time being.

When trying to switch to uv, it deleted all of /usr/local. Not my best day.

The python virtual env should manage
- pyvenv.cfg
- lib/pythonx.y
- generated entrypoints in bin

And nothing else. Untill very recently this was the case.

I agree to this for development.
But for using a package in production, I don't want to deploy to some hidden .venv and then be forced to use symlinks to have logical more sane, structure.
Only recently this become a problem with uv mindlessly deleting .venv-folders.
This is wrong behaviour.

Dissent among humans is probably not the real problem on X.

Nice overview (thanks to @lukasz.langa.pl by sharing on X)
www.youtube.com/watch?v=GZ5X...

Jammer van de wisselvalligheid van dit filmpje. Zeer sterke argumenten afgewisseld met onjuistheden.

I wish we had some grand visionaries like Jacques Delors to move the EU forward. Currently I don't see anyone fitting that description.

"Skeet" sounds much like "scheet" in Dutch, meaning fart.

Found memories of "1st Page 2000" from Evrsoft, released in 1999. After 25y their original website is still online at
www.evrsoft.com/company.shtml