5 ms·

This isn't a comment just about Python.. but it should just work. There shouldn't be constant ceremony for getting and keeping environments running.

by j45 1y ago

oblio 1y ago
There are basically 0 other programming languages that use the "directory/shell integration activated virtual environment", outside of Python. How does the rest of the world manage to survive without venvs? Config files in the directory. Shocking, really :-)))
- roflyear 1y ago
  what happens when you have two projects using different versions of node, etc? isn't that a massive headache? not that it's great to start with, but it does happen, no?
  - oblio 1y ago
    The rest of the world handles that through PATH/PATH equivalent. Either the package manager is invoked with a different PATH (one that contains the desired Node/Java/whatever version as a higher priority item than any other version on the system). Or the package manager itself has some way to figure that out through its config file. Or there is a package manager launch tool, just like pyenv or whatever, which does that for you. In practice it's not that a big of a deal, even for Maven, a tool created 21 years ago. As the average software dev you figure that stuff out a few weeks into using the tool, maybe you get burnt a few times early on for misconfiguring it and then you're on autopilot for the rest of your career. Wait till you hear about Java's CLASSPATH and the idea of having a SINGLE, UNIFIED package dependency repo on your system, with no need for per-project dependency repos (node_modules), symlinks, or all of that stupidity. CLASSPATH was introduced by Java in 1996, I think, and popularized for Java dependency management in 2004.
    - 1718627440 1y ago
      Well, that is how Python does it as well, an venv is a script setting the PYTHONPATH.
      - zahlman 1y ago
        This is wrong. A venv is a hierarchy of folders containing a config file, as well as some symlinks to Python (or stub executables on Windows). "How Python does it" is that when it starts up from the symlink, it looks for the config file at a relative path; if that checks out, it uses hard-coded rules to add another relative path to sys.path. PYTHONPATH is never involved. The venvs created by the standard library `venv`, as well as by uv (and by the third-party `virtualenv` that formed the original basis for `venv`), also happen to include "activation" scripts that manipulate some environment variables. PYTHONPATH is not among these. It manipulates PATH, so that the venv's symlink is on the path. And it may unset PYTHONHOME.
    - dragonwriter 1y ago
      > The rest of the world handles that through PATH/PATH equivalent. Activating a venv is just setting a few environment variables, including PATH, and storing the old values so that you can put them back to deactivate the environment.
      - oblio 1y ago
        It's also putting dependencies in a certain folder in a setup that isn't even portable between machines. Probably some other stuff I'm forgetting.
  - cluckindan 1y ago
    You create a .node-version file and use fnm or nvm, and presto, when you cd into a project dir, the corresponding node version is activated. Installing a particular node version also becomes as easy as fnm install 24
- whywhywhywhy 1y ago
  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....
- zahlman 1y ago
  > Config files in the directory. The problem is, that would require support from the Python runtime itself (so that `sys.path` can be properly configured at startup) and it would have to be done in a way that doesn't degrade the experience for people who aren't using a proper "project" setup. One of the big selling points of Python is that you can just create a .py file anywhere, willy-nilly, and execute the code with a Python interpreter, just as you would with e.g. a Bash script. And that you can incrementally build up from there, as you start out learning programming, to get a sense of importing files, and then creating meaningful "projects", and then thinking about packaging and distribution.
  - 1718627440 1y ago
    There are path configuration files (*.pth) and you can configure sys.path in the script itself?
    - zahlman 1y ago
      Yes, and in principle you can install each package into a separate folder (see the `--target` option for pip) and configure sys.path manually like that. For .pth files to work, they have to be in a place where the standard library `site` module will look. You can add your own logic to `sitecustomize.py` and/or `usercustomize.py` but then you're really no better off vs. writing the sys.path manipulation logic. Many years ago, the virtual environment model was considered saner, for whatever reasons. (I've actually heard people cite performance considerations from having an overly long `sys.path`, but I really doubt that matters.) And it's stuck.
  - 9dev 1y ago
    And how is that different from any other interpreted language? Node and PHP handle this just fine, and they don’t need a Rube Goldberg contraption to load dependencies from a relative directory or the systems library path. I really don’t get why Python people act like that’s some kind of wicked witchcraft?
    - t43562 1y ago
- j45 1y ago
  The venv thing def stands out to me as being a bit of an outlier. If uv makes it invisible it is a step forward.
- cluckindan 1y ago
  Node.js does, if you use fnm or nvm.
- zelphirkalt 1y ago
  By requiring special tooling to build and run your program. Namely cargo, npm, etc, while in Python these are a bit more separate concerns.
1718627440 1y ago
It does, Python has essentially solved it for years.
- bschwindHN 1y ago
  lol no it hasn't Why else is this discussion getting hundreds of comments? For any random python tool out there, I had about a 60% chance it would work out of the box. uv is the first tool in the python ecosystem that has brought that number basically to 100%. Ironically, it's written in Rust because python does not lend itself well to distributing reliable, fast tools to end users.
  - 1718627440 1y ago
    The language (actually the standard implementations build system) has. The problem is programs and installations don't use it.
  - zelphirkalt 1y ago
    It comes up again and again, because people don't realize that solutions already exist(ed) and they don't spend the time to figure things out. I have managed reproducible Python services and software for multiple years now. This was solved already before uv, although uv does it faster and maybe offers a bit more comfort, although I abstract away such tooling using a simple Makefile anyway. The reason you are having such a bad time getting random Python projects to work out of the box is, because people creating them did not spend the effort to make them reproducible, meaning, that they do not ensure the setup has same versions and checksums of every direct and transitive dependency. This can be facilitated using various tools these days. poetry, uv, and I am sure there are more. People are just clueless and think that a requirements.txt file with a few loose versions slung in is sufficient. It is not, and you end up with not working project setups like in those cases you refer to.
  - zahlman 1y ago
    > For any random python tool out there, I had about a 60% chance it would work out of the box. Had, past tense, because of the metadata situation and the lack of pre-built wheels. The ecosystem has moved on. > uv is the first tool in the python ecosystem that has brought that number basically to 100%. Show me a Python tool that you can install and have work out-of-box with uv, but cannot install and have work out-of-box with pip. > Ironically, it's written in Rust because python does not lend itself well to distributing reliable, fast tools to end users. I have repeatedly shown that the slowness of pip is overwhelmingly due to its terrible (organically developed on top of legacy cruft from an era where people simply didn't have the same requirements) architecture, not due to being written in Python. Most of the work of installation is simply not CPU-bound — why would it be? — and the main task that is (optional pre-compilation of Python source to .pyc) is one of the few things where uv is dependent on the Python runtime (which, in turn, will do the work in C).

This isn't a comment just about Python.. but it should just work. There shouldn't be constant ceremony for getting and keeping environments running.

by j45 1y ago

This isn't a comment just about Python.. but it should just work. There shouldn't be constant ceremony for getting and keeping environments running.

oblio 1y ago

There are basically 0 other programming languages that use the "directory/shell integration activated virtual environment", outside of Python. How does the rest of the world manage to survive without venvs? Config files in the directory. Shocking, really :-)))

roflyear 1y ago
what happens when you have two projects using different versions of node, etc? isn't that a massive headache? not that it's great to start with, but it does happen, no?
- oblio 1y ago
  The rest of the world handles that through PATH/PATH equivalent. Either the package manager is invoked with a different PATH (one that contains the desired Node/Java/whatever version as a higher priority item than any other version on the system). Or the package manager itself has some way to figure that out through its config file. Or there is a package manager launch tool, just like pyenv or whatever, which does that for you. In practice it's not that a big of a deal, even for Maven, a tool created 21 years ago. As the average software dev you figure that stuff out a few weeks into using the tool, maybe you get burnt a few times early on for misconfiguring it and then you're on autopilot for the rest of your career. Wait till you hear about Java's CLASSPATH and the idea of having a SINGLE, UNIFIED package dependency repo on your system, with no need for per-project dependency repos (node_modules), symlinks, or all of that stupidity. CLASSPATH was introduced by Java in 1996, I think, and popularized for Java dependency management in 2004.
  - 1718627440 1y ago
    Well, that is how Python does it as well, an venv is a script setting the PYTHONPATH.
    - zahlman 1y ago
      This is wrong. A venv is a hierarchy of folders containing a config file, as well as some symlinks to Python (or stub executables on Windows). "How Python does it" is that when it starts up from the symlink, it looks for the config file at a relative path; if that checks out, it uses hard-coded rules to add another relative path to sys.path. PYTHONPATH is never involved. The venvs created by the standard library `venv`, as well as by uv (and by the third-party `virtualenv` that formed the original basis for `venv`), also happen to include "activation" scripts that manipulate some environment variables. PYTHONPATH is not among these. It manipulates PATH, so that the venv's symlink is on the path. And it may unset PYTHONHOME.
  - dragonwriter 1y ago
    > The rest of the world handles that through PATH/PATH equivalent. Activating a venv is just setting a few environment variables, including PATH, and storing the old values so that you can put them back to deactivate the environment.
    - oblio 1y ago
      It's also putting dependencies in a certain folder in a setup that isn't even portable between machines. Probably some other stuff I'm forgetting.
- cluckindan 1y ago
  You create a .node-version file and use fnm or nvm, and presto, when you cd into a project dir, the corresponding node version is activated. Installing a particular node version also becomes as easy as fnm install 24
whywhywhywhy 1y ago
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....
zahlman 1y ago
> Config files in the directory. The problem is, that would require support from the Python runtime itself (so that `sys.path` can be properly configured at startup) and it would have to be done in a way that doesn't degrade the experience for people who aren't using a proper "project" setup. One of the big selling points of Python is that you can just create a .py file anywhere, willy-nilly, and execute the code with a Python interpreter, just as you would with e.g. a Bash script. And that you can incrementally build up from there, as you start out learning programming, to get a sense of importing files, and then creating meaningful "projects", and then thinking about packaging and distribution.
- 1718627440 1y ago
  There are path configuration files (*.pth) and you can configure sys.path in the script itself?
  - zahlman 1y ago
    Yes, and in principle you can install each package into a separate folder (see the `--target` option for pip) and configure sys.path manually like that. For .pth files to work, they have to be in a place where the standard library `site` module will look. You can add your own logic to `sitecustomize.py` and/or `usercustomize.py` but then you're really no better off vs. writing the sys.path manipulation logic. Many years ago, the virtual environment model was considered saner, for whatever reasons. (I've actually heard people cite performance considerations from having an overly long `sys.path`, but I really doubt that matters.) And it's stuck.
- 9dev 1y ago
  And how is that different from any other interpreted language? Node and PHP handle this just fine, and they don’t need a Rube Goldberg contraption to load dependencies from a relative directory or the systems library path. I really don’t get why Python people act like that’s some kind of wicked witchcraft?
  - t43562 1y ago
j45 1y ago
The venv thing def stands out to me as being a bit of an outlier. If uv makes it invisible it is a step forward.
cluckindan 1y ago
Node.js does, if you use fnm or nvm.
zelphirkalt 1y ago
By requiring special tooling to build and run your program. Namely cargo, npm, etc, while in Python these are a bit more separate concerns.

1718627440 1y ago

It does, Python has essentially solved it for years.

bschwindHN 1y ago
lol no it hasn't Why else is this discussion getting hundreds of comments? For any random python tool out there, I had about a 60% chance it would work out of the box. uv is the first tool in the python ecosystem that has brought that number basically to 100%. Ironically, it's written in Rust because python does not lend itself well to distributing reliable, fast tools to end users.
- 1718627440 1y ago
  The language (actually the standard implementations build system) has. The problem is programs and installations don't use it.
- zelphirkalt 1y ago
  It comes up again and again, because people don't realize that solutions already exist(ed) and they don't spend the time to figure things out. I have managed reproducible Python services and software for multiple years now. This was solved already before uv, although uv does it faster and maybe offers a bit more comfort, although I abstract away such tooling using a simple Makefile anyway. The reason you are having such a bad time getting random Python projects to work out of the box is, because people creating them did not spend the effort to make them reproducible, meaning, that they do not ensure the setup has same versions and checksums of every direct and transitive dependency. This can be facilitated using various tools these days. poetry, uv, and I am sure there are more. People are just clueless and think that a requirements.txt file with a few loose versions slung in is sufficient. It is not, and you end up with not working project setups like in those cases you refer to.
- zahlman 1y ago
  > For any random python tool out there, I had about a 60% chance it would work out of the box. Had, past tense, because of the metadata situation and the lack of pre-built wheels. The ecosystem has moved on. > uv is the first tool in the python ecosystem that has brought that number basically to 100%. Show me a Python tool that you can install and have work out-of-box with uv, but cannot install and have work out-of-box with pip. > Ironically, it's written in Rust because python does not lend itself well to distributing reliable, fast tools to end users. I have repeatedly shown that the slowness of pip is overwhelmingly due to its terrible (organically developed on top of legacy cruft from an era where people simply didn't have the same requirements) architecture, not due to being written in Python. Most of the work of installation is simply not CPU-bound — why would it be? — and the main task that is (optional pre-compilation of Python source to .pyc) is one of the few things where uv is dependent on the Python runtime (which, in turn, will do the work in C).