5 ms·

IMO what needs to happen is python needs to get rid of system installs and only work via venv. It should check the current folder for some .venv or something an

by nox101 2y ago

IMO what needs to happen is python needs to get rid of system installs and only work via venv. It should check the current folder for some .venv or something and auto-config itself to the current directory (or complain that you need to config with a messages like "python not configured for current folder. Run 'source bin/activate' to configure. Honestly thought that could be so much better. The entire problem of python an venv IMO comes from it not being the default.

polemic 2y ago
Python developers agree. See PEP 668 – Marking Python base environments as “externally managed” – https://peps.python.org/pep-0668/ https://peps.python.org/pep-0668/
- brylie 2y ago
  More recent document https://packaging.python.org/en/latest/specifications/externally-managed-environments/#externally-managed-environments https://packaging.python.org/en/latest/specifications/extern...
  - ajb 2y ago
    Hmm that still recommends that distros allow admins to install to /usr/local, albeit in such a way that it at least can't break the OS. IMO the idea that a 'Linux admin' is better informed than a 'Linux user' is increasingly anachronistic. In most cases the admin is just the user running sudo. I'd suggest that such functionality should be enabled by installing some kind of OS package rather than being the default
- jampekka 2y ago
  Yet another hack on hack. Venv was the wrong fix/hack and now the package management is cascading into even more madness.
- lhfacx 2y ago
  This is insane. Apparently (at least on Debian) this can be circumvented by putting this in ~/.config/pip/pip.conf: [global] break-system-packages = true I would have preferred single-version-externally-managed to keep fond memories of setuptools alive. It becomes increasingly impossible to track down home directory pollution and config files in Python. Next step will be a Python registry on Linux. How about: regedit VENV=/home/sjw/venv42 KEYWORD=single-version-externally-managed DWORD=0xbadbee
delusional 2y ago
This is already the case on Arch, where pip will yell at you if you try to install anything to either the user or system score.
mrweasel 2y ago
That depends very much on what you're doing. For production I'd like to use the OS package manager to install my Python dependencies, and move the responsibility of patching to the OS. For workstations, absolutely, go with virtual environments, it's the only way to go. One concern I've seen from some in the machine learning space is that rebuilding a virtual environment, for example if macOS upgrades the Python version, takes hours. That can be solved by using pyenv, then you can have multiple versions of Python and be free of Anaconda. I primarily use pyenv to be sure that I have the same Python version that ships with the server OS on my laptop.
- flessner 2y ago
  I have been out of the loop with Python for a couple years at this point, but how could this get so bad? If you are looking into a system you are unfamiliar with, where do you look first?... pip? pipx? homebrew?... or is it in anaconda? pyenv?... must be in the os package manager... apt? pacman? Honestly, Maven and NPM look great compared to this mess.
  - mrweasel 2y ago
    NPM to me is the great example of a package manager that worse than anything the Python community has come up with, but that's subjective I think. Python isn't as bad as people make it out to be. There are some issue that you will run into if your project/code base becomes really large, but that's not an issue for most people. The vast majority can get just use python -mvenv .venv to set up a virtual environment and install in that using pip. Next step up is you need specific versions of Python, so you switch to pyenv, which functions mostly like the built in virtualenv. Then you have the special cases where you need to lock dependencies much hard than pip can do and you use poetry, pip is to slow so you use pipx. Those are edge cases to be honest. That's not to say that they aren't solving very real problem, but mostly you don't need it. It would be great if there was one tools that could do it all, lock the Python version, do quick dependency resolution and lock them down. So far Python has opted to split the problem: Tools for locking the Python version, tools for creating separate environments and tools for managing packages. There's a lot of crossover in the first two, but you can pretty much mix and match virtual environment tools and package managers anyway you like. I think that's pretty unique.
eddyg 2y ago
I always set: export PIP_REQUIRE_VIRTUALENV=true

by nox101 2y ago

polemic 2y ago

Python developers agree. See PEP 668 – Marking Python base environments as “externally managed” – https://peps.python.org/pep-0668/ https://peps.python.org/pep-0668/

brylie 2y ago
More recent document https://packaging.python.org/en/latest/specifications/externally-managed-environments/#externally-managed-environments https://packaging.python.org/en/latest/specifications/extern...
- ajb 2y ago
  Hmm that still recommends that distros allow admins to install to /usr/local, albeit in such a way that it at least can't break the OS. IMO the idea that a 'Linux admin' is better informed than a 'Linux user' is increasingly anachronistic. In most cases the admin is just the user running sudo. I'd suggest that such functionality should be enabled by installing some kind of OS package rather than being the default
jampekka 2y ago
Yet another hack on hack. Venv was the wrong fix/hack and now the package management is cascading into even more madness.
lhfacx 2y ago
This is insane. Apparently (at least on Debian) this can be circumvented by putting this in ~/.config/pip/pip.conf: [global] break-system-packages = true I would have preferred single-version-externally-managed to keep fond memories of setuptools alive. It becomes increasingly impossible to track down home directory pollution and config files in Python. Next step will be a Python registry on Linux. How about: regedit VENV=/home/sjw/venv42 KEYWORD=single-version-externally-managed DWORD=0xbadbee

delusional 2y ago

This is already the case on Arch, where pip will yell at you if you try to install anything to either the user or system score.

mrweasel 2y ago

That depends very much on what you're doing. For production I'd like to use the OS package manager to install my Python dependencies, and move the responsibility of patching to the OS. For workstations, absolutely, go with virtual environments, it's the only way to go. One concern I've seen from some in the machine learning space is that rebuilding a virtual environment, for example if macOS upgrades the Python version, takes hours. That can be solved by using pyenv, then you can have multiple versions of Python and be free of Anaconda. I primarily use pyenv to be sure that I have the same Python version that ships with the server OS on my laptop.

flessner 2y ago
I have been out of the loop with Python for a couple years at this point, but how could this get so bad? If you are looking into a system you are unfamiliar with, where do you look first?... pip? pipx? homebrew?... or is it in anaconda? pyenv?... must be in the os package manager... apt? pacman? Honestly, Maven and NPM look great compared to this mess.
- mrweasel 2y ago
  NPM to me is the great example of a package manager that worse than anything the Python community has come up with, but that's subjective I think. Python isn't as bad as people make it out to be. There are some issue that you will run into if your project/code base becomes really large, but that's not an issue for most people. The vast majority can get just use python -mvenv .venv to set up a virtual environment and install in that using pip. Next step up is you need specific versions of Python, so you switch to pyenv, which functions mostly like the built in virtualenv. Then you have the special cases where you need to lock dependencies much hard than pip can do and you use poetry, pip is to slow so you use pipx. Those are edge cases to be honest. That's not to say that they aren't solving very real problem, but mostly you don't need it. It would be great if there was one tools that could do it all, lock the Python version, do quick dependency resolution and lock them down. So far Python has opted to split the problem: Tools for locking the Python version, tools for creating separate environments and tools for managing packages. There's a lot of crossover in the first two, but you can pretty much mix and match virtual environment tools and package managers anyway you like. I think that's pretty unique.

eddyg 2y ago

I always set: export PIP_REQUIRE_VIRTUALENV=true