3 ms·

The most likely outcome at this point is more ways to do it not less. Because we've arrived at the point where nobody is willing to give up on their favourite m

by ggm 2y ago

The most likely outcome at this point is more ways to do it not less. Because we've arrived at the point where nobody is willing to give up on their favourite method. I think it may be in the class of things Python people COULD fix but WONT fix. For me, the biggest bugbear is how often you need to work through pip not liking install frameworks like brew. It drives very strongly to telling you to "virtualise" but that means having link farms and context specific execution envirements baked into your praxis. If (like me) you're used to just vi /tmp/file.py and hacking, the burdens of pip not wanting to break things (tm) become high. Could e.g. python not have SYSPATH:OTHERPATH:VERSION-SPECIFIC-PATH:~/.PYENV: included in it, so we can install pip stuff in homedirs and not have to worry about smashing the system install? (avalanche of "bad idea because.." coming) Perl kind of had this. You can live with old perl libs through at most one ENV setting to point to your install path.

zahlman 2y ago
> but that means having link farms and context specific execution envirements baked into your praxis. It's nowhere near as onerous as you make it sound. I get the impression that you miss the experience of having a single environment that you can hack in to your heart's content, deal with package conflicts within that environment when you come to them, and stay isolated away from the system. Here's one way to do that step by step on Debian: $ sudo apt-get python3-venv python3-pip $ python3 -m venv ~/Desktop/hack-venv $ alias hack-python='~/Desktop/hack-venv/bin/python' $ alias hack-pip='~/Desktop/hack-venv/bin/pip' I started out with something similar before evolving more sophisticated strategies that I need as a developer. You might also prefer to build from source, install with some prefix, and use it directly. > Could e.g. python not have SYSPATH:OTHERPATH:VERSION-SPECIFIC-PATH:~/.PYENV: included in it, That's exactly what virtual environments do. For example, on Linux, the SYSPATH:OTHERPATH part is `/usr` for the system Python, or the path to a virtual environment; the VERSION-SPECIFIC-PATH is `lib/python3.x/site-packages` (where `x` is replaced with the appropriate minor version). The entire point of setting up a virtual environment is that you choose a separate SYSPATH:OTHERPATH part, (and it sets up the other sub-folders, depending on the Python version for that environment) so that you can have a separate folder where you put libraries specific to that environment. > so we can install pip stuff in homedirs and not have to worry about smashing the system install? You can install for the system install in a specific home directory, using the `--user` flag for Pip. (On newer systems that have opted into the new protection scheme, you also need `--break-system-packages` - it's named like that for a reason.) Python's startup process will add that folder to `sys.path` automatically when you run the system Python. This allows you to install those things without admin privileges (so you don't run arbitrary code as root from someone's `setup.py`) But such packages can still "smash" the system install because of how absolute imports work - the package that you install could shadow a name of something that a system-installed library wants to `import`. That's why the new "externally-managed-environment" system exists (https://software.codidact.com/posts/291839 https://software.codidact.com/posts/291839). If you want some other environment to use that same home directory (or another one of your choosing), you can add a `.pth` file to its `site-packages`. If you want every environment to use it, set the PYTHONPATH environment variable (and you can also use a command-line flag to disable considering PYTHONPATH). These techniques are fully documented starting from https://docs.python.org/3/library/sys_path_init.html https://docs.python.org/3/library/sys_path_init.html ; you should also read the documentation for the `site` standard library module that runs by default at startup (https://docs.python.org/3/library/site.html https://docs.python.org/3/library/site.html).

by ggm 2y ago

zahlman 2y ago

> but that means having link farms and context specific execution envirements baked into your praxis. It's nowhere near as onerous as you make it sound. I get the impression that you miss the experience of having a single environment that you can hack in to your heart's content, deal with package conflicts within that environment when you come to them, and stay isolated away from the system. Here's one way to do that step by step on Debian: $ sudo apt-get python3-venv python3-pip $ python3 -m venv ~/Desktop/hack-venv $ alias hack-python='~/Desktop/hack-venv/bin/python' $ alias hack-pip='~/Desktop/hack-venv/bin/pip' I started out with something similar before evolving more sophisticated strategies that I need as a developer. You might also prefer to build from source, install with some prefix, and use it directly. > Could e.g. python not have SYSPATH:OTHERPATH:VERSION-SPECIFIC-PATH:~/.PYENV: included in it, That's exactly what virtual environments do. For example, on Linux, the SYSPATH:OTHERPATH part is `/usr` for the system Python, or the path to a virtual environment; the VERSION-SPECIFIC-PATH is `lib/python3.x/site-packages` (where `x` is replaced with the appropriate minor version). The entire point of setting up a virtual environment is that you choose a separate SYSPATH:OTHERPATH part, (and it sets up the other sub-folders, depending on the Python version for that environment) so that you can have a separate folder where you put libraries specific to that environment. > so we can install pip stuff in homedirs and not have to worry about smashing the system install? You can install for the system install in a specific home directory, using the `--user` flag for Pip. (On newer systems that have opted into the new protection scheme, you also need `--break-system-packages` - it's named like that for a reason.) Python's startup process will add that folder to `sys.path` automatically when you run the system Python. This allows you to install those things without admin privileges (so you don't run arbitrary code as root from someone's `setup.py`) But such packages can still "smash" the system install because of how absolute imports work - the package that you install could shadow a name of something that a system-installed library wants to `import`. That's why the new "externally-managed-environment" system exists (https://software.codidact.com/posts/291839 https://software.codidact.com/posts/291839). If you want some other environment to use that same home directory (or another one of your choosing), you can add a `.pth` file to its `site-packages`. If you want every environment to use it, set the PYTHONPATH environment variable (and you can also use a command-line flag to disable considering PYTHONPATH). These techniques are fully documented starting from https://docs.python.org/3/library/sys_path_init.html https://docs.python.org/3/library/sys_path_init.html ; you should also read the documentation for the `site` standard library module that runs by default at startup (https://docs.python.org/3/library/site.html https://docs.python.org/3/library/site.html).