> why are we using an OS level command to activate a programming language's environment
Because "activating an environment" means setting environment variables in the parent process (the shell that you use to run the command), which is otherwise impossible on Linux (see for example https://stackoverflow.com/questions/6943208).
> why is this hidden anyway, doesn't that just make it more confusing for people coming to the language
It doesn't have to be. You can call it anything you want, hidden or not, and you can put it anywhere in the filesystem. It so happens that many people adopted this convention because they liked having the venv in that location and hidden; and uv gives such venvs special handling (discovering and using them by default).
> why is this the most generic name possible as if no other element in a system might need to be called the activate command over something as far down the chain as a python environment
Because the entire point is that, when you need to activate the environment, the folder in question is not on the path (the purpose of the script is to put it on the path!).
If activating virtual environments shadows e.g. /usr/bin/activate on your system (because the added path will be earlier in $PATH), you can still access that with a full absolute path; or you can forgo activation and do things like `.venv/bin/python -m foo`, `.venv/bin/my-program-wrapper`, etc.
> Feels dirty every time I've had to type it out
I use this:
$ type activate-local
activate-local is aliased to `source .local/.venv/bin/activate'
$ cat .local/.gitignore
# Anything found in this subdirectory will be ignored by Git.
# This is a convenient place to put unversioned files relevant to your
# working copy, without leaving any trace in the commit history.
*
If you know anyone who's hiring....
Fair response it's just nothing else feels like this weird duct tape'd together bunch of hacks to work around the design mistakes of the base language assuming it's a top level part of the OS.
> which is otherwise impossible on Linux
Node, Rust, etc all manage it.
> Because the entire point is that...
I just mean there is a history of Python using overly generic naming: activate, easy-install. Just feels weird and dirty to me that you'd call such a specific things names like these and I think it's indicative of this ideology that Python is deep in the OS.
Maybe if I'd aliased the activate command a decade ago I wouldn't feel this way or think about it.
> Node, Rust, etc all manage it.
How do they work around this?You're arguing an awful lot in favor of Python venvs for someone who doesn't really seem to know any other programming language ecosystems in depth.
Similar mindset to the original creators of venv, I imagine :-)
Or you don't realize the difference between something like "cargo run" and "python file.py".
They don’t use environment variables. See also git.
... And as I explained repeatedly in multiple other posts throughout the thread, you can also use virtual environments without activating them, in which case you are similarly not using environment variables.
The git model is based on automatic detection of the .git folder, by having it in a location determined by convention. Many higher-level tools in the Python ecosystem have provided analogous handling of virtual environments over the years. Uv is doing it now; historically pyenv was used for that sort of thing, for example.
But when I said "which is otherwise impossible on Linux", I was specifically referring to the setting of environment variables, because OP asked why an activation script had to be sourced, and the reason is because that's what "activation" is.
This is a model that enough people liked using many years ago, to become dominant. It creates the abstraction of being "in" the virtual environment, while giving you the flexibility to put the actual file tree whereever you want.