The next Debian/Ubuntu releases will no longer allow `pip install` outside of a venv: https://discuss.python.org/t/pep-668-marking-python-base-env...
You can still force it via `pip install --break-system-packages ...` if needed.
One does not simply 'pip install'
11–20 of 118 posts
Re: One does not simply 'pip install'
#12I'm not sure if I get the point of this article. So basically the author has learnt that there are a different ways of managing packages in Python? I'm aware that this might be a problem in Python, but let's be serious guys, you only need to spend 5 mins to learn about venv/conda and you will never face any problem in a basic Python project. You don't have to write an article about that.
Re: One does not simply 'pip install'
#13Pyenv virtualenv is my personal fav for this issue
Re: One does not simply 'pip install'
#14Just use Docker.
Re: One does not simply 'pip install'
#15Earlier quoted context omitted.
The lack of one true package management approach is a failure of the language. OP is advocating for a saner default like npm, instead of the current venv + pip mess.
I like venv/pip. I can blow out the directory when I am done with it. I do not need to remember what is installed were. Compare this to my GOPATH/GOROOT which is insanely full of mods...gigabytes...
npm has the same property of keeping the files locally, but without any need to activate/deactivate a venv. It “just works” that way by default if you “npm install”
Re: One does not simply 'pip install'
#16While I agree with the author to not do global pip installs for every new project, I also don’t want to see text in every git repo README explaining Python package managers.
The lack of one true package management approach is a failure of the language. OP is advocating for a saner default like npm, instead of the current venv + pip mess.
Npm, yarn, yarn2, pnp, pnpm, and more.
The only thing they have in common is package.json, but even then they can interpret things differently, such as workspaces.
And then node_modules, which packages should not rely on but do, forcing many other tools into compatibility mode which often takes an install take a very long time.
Yes, the node ecosystem is very healthy.
Re: One does not simply 'pip install'
#17The next Debian/Ubuntu releases will no longer allow `pip install` outside of a venv: https://discuss.python.org/t/pep-668-marking-python-base-env... You can still force it via `pip install --break-system-packages ...` if needed.
The way it's meant to be.
On Linux, you either use the system packages via "apt install", or you use venvs.
EDIT: For context, I've meant "managed" distros like Debian and Ubuntu.
Re: One does not simply 'pip install'
#18Pyenv virtualenv is my personal fav for this issue
+1. The lack of mention of pyenv and pyenv-virtualenv is surprisingly common but has always been my best experience.
Re: One does not simply 'pip install'
#19Earlier quoted context omitted.
I like venv/pip. I can blow out the directory when I am done with it. I do not need to remember what is installed were. Compare this to my GOPATH/GOROOT which is insanely full of mods...gigabytes...
npm has the same property of keeping the files locally, but without any need to activate/deactivate a venv. It “just works” that way by default if you “npm install”
Once you create a venv, you can just refer to its path. I always disliked the whole activate/deactivate steps.
Re: One does not simply 'pip install'
#20Earlier quoted context omitted.
The lack of one true package management approach is a failure of the language. OP is advocating for a saner default like npm, instead of the current venv + pip mess.
Npm, yarn, yarn2, pnp, pnpm, and more. The only thing they have in common is package.json, but even then they can interpret things differently, such as workspaces. And then node_modules, which packages should not rely on but do, forcing many other tools into compatibility mode which often takes an install take a very long time. Yes, the node ecosystem is very healthy.
> And then node_modules, which packages should not rely on but do,
Isn't the point of node_modules to house ... dependencies? I'm confused as to what you're getting at here.