4 ms·

The only word in the `source .venv/bin/activate` command that isn't a complete red flag that this was the wrong approach is probably bin. Everything else is so

The only word in the `source .venv/bin/activate` command that isn't a complete red flag that this was the wrong approach is probably bin. Everything else is so obviously wrong. source - why are we using an OS level command to activate a programming language's environment .venv - why is this hidden anyway, doesn't that just make it more confusing for people coming to the language activate - 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 Feels dirty every time I've had to type it out and find it particularly annoying when Python is pushed so much as a good first language and I see people paid at a senior level not understand this command.

zahlman 1y ago
> 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 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' Notice that, again, you don't have to put it at .venv . I use a .local folder to store notes that I don't want to publish in my repo nor mention in my project's .gitignore; it in turn has $ 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. * > and I see people paid at a senior level not understand this command. If you know anyone who's hiring....
- whywhywhywhy 1y ago
  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.
  - zahlman 1y ago
    > Node, Rust, etc all manage it. $ (bash -c 'export foo=bar && echo $foo') bar $ echo $foo $ How do they work around this?
    - baq 1y ago
      They don’t use environment variables. See also git.
      - zahlman 1y ago
        ... 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.
j45 1y ago
Maybe it's just me, but it shouldn't be necessary to manage this and a few other things to get a python script working. uv has increased my usage of python for production purposes because it's maintainable by a larger group of people, and beginners can become competent that much quicker.
- t43562 1y ago
  One could say ... why do people not bother to learn the shell, or how programs get environment settings ...or how to write shell function to run activate for themselves or how to create a tiny makefile which would do all of this for them? Surely the effort of programming the actual code is so significant that starting a tool is a minor issue?
  - SAI_Peregrinus 1y ago
    Because the effort of programming the actual code is often less than figuring out how to glue together a dozen different inane tools with inexplicably different usage conventions. KISS always matters, and UV keeps it very simple. Small is often the opposite of simple.
    - t43562 1y ago
      I think this happens because in the ML world particularly, there's an unusually pressured situation. Why are people not using the system python? Perhaps it's too old or not old enough for some library that they have to use. This suggests there's a lot of change going on at the moment and it's not all synced up. I also suspect that people are using a very great number of different modules that change incompatibly all the time and ontop of that they need binary libraries of various kinds which are quite difficult to build and have all their own dependencies that python cannot install itself. Rust has the advantage that they can build a world more completely out of rust and not worry as much about what's on the system already. I'm glad uv is helping people.
      - SAI_Peregrinus 1y ago

zahlman 1y ago

> 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 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' Notice that, again, you don't have to put it at .venv . I use a .local folder to store notes that I don't want to publish in my repo nor mention in my project's .gitignore; it in turn has $ 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. * > and I see people paid at a senior level not understand this command. If you know anyone who's hiring....

whywhywhywhy 1y ago
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.
- zahlman 1y ago
  > Node, Rust, etc all manage it. $ (bash -c 'export foo=bar && echo $foo') bar $ echo $foo $ How do they work around this?
  - baq 1y ago
    They don’t use environment variables. See also git.
    - zahlman 1y ago
      ... 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.

j45 1y ago

Maybe it's just me, but it shouldn't be necessary to manage this and a few other things to get a python script working. uv has increased my usage of python for production purposes because it's maintainable by a larger group of people, and beginners can become competent that much quicker.

t43562 1y ago
One could say ... why do people not bother to learn the shell, or how programs get environment settings ...or how to write shell function to run activate for themselves or how to create a tiny makefile which would do all of this for them? Surely the effort of programming the actual code is so significant that starting a tool is a minor issue?
- SAI_Peregrinus 1y ago
  Because the effort of programming the actual code is often less than figuring out how to glue together a dozen different inane tools with inexplicably different usage conventions. KISS always matters, and UV keeps it very simple. Small is often the opposite of simple.
  - t43562 1y ago
    I think this happens because in the ML world particularly, there's an unusually pressured situation. Why are people not using the system python? Perhaps it's too old or not old enough for some library that they have to use. This suggests there's a lot of change going on at the moment and it's not all synced up. I also suspect that people are using a very great number of different modules that change incompatibly all the time and ontop of that they need binary libraries of various kinds which are quite difficult to build and have all their own dependencies that python cannot install itself. Rust has the advantage that they can build a world more completely out of rust and not worry as much about what's on the system already. I'm glad uv is helping people.
    - SAI_Peregrinus 1y ago