Poetry is pretty much the way to go.
One does not simply 'pip install'
111–118 of 118 posts
Re: One does not simply 'pip install'
#112When I switched to Arch Linux, I learned that pip has a --user option to install Python packages in the home dir of the current user. This is essential to not interfere with the system install from the system package manager. I had really trouble with that in former times.
Furthermore, as I now be used to bleeding edge packages, I update at least once a week all the outdated Python packages of my >450 installed ones. When some packages get downgraded because of requirements, I ask: Do I need the package that caused the downgrade more often or with more of the packages in the main environment, or is this true for one or some of the downgraded packages?
According to the answer, I put the 'problematic' package(s) in a new or existing venv, and update the downgraded ones in the main environment, if necessary.
This work cannot be done by a package manager!
Costs me <10 minutes every week to keep the main environment up to date, a bit more if I want that for some or all venvs.
Re: One does not simply 'pip install'
#113Earlier 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...
I'd gladly take $1 worth of storage over venv/pip mess. > Compare this to my GOPATH/GOROOT which is insanely full of mods...gigabytes... Go apps are self-contained blobs. You can just... not install it ? `go build` will just leave you with binary blob in root dir you can put whenever.
Building means downloading dependencies means an ever-growing module cache with no ability to prune it.
Re: One does not simply 'pip install'
#114The article talks about installing Python packages for development, but if you find yourself using `pip` to install Python tools/scripts then you should use `pipx` - it will properly sandbox those tools so they don't break (or be broken by) the system or other Pythons: https://pypa.github.io/pipx/
The problem is that everyone has different problems with python packaging and everyone has different idea what you "should" do.
Not really.
Pipx uses the ecosystem standard of "make a venv" and it just exposes the binary entrypoint of what you installed.
It is exactly what everything says you should do, because everyone agrees. It just does it for you.
Re: One does not simply 'pip install'
#115Earlier quoted context omitted.
I'd gladly take $1 worth of storage over venv/pip mess. > Compare this to my GOPATH/GOROOT which is insanely full of mods...gigabytes... Go apps are self-contained blobs. You can just... not install it ? `go build` will just leave you with binary blob in root dir you can put whenever.
Building means downloading dependencies means an ever-growing module cache with no ability to prune it.
rm -rf ~/go
Re: One does not simply 'pip install'
#116The 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.
PEP 704 is a recent proposal to require a virtual environment by default for any package installer - https://peps.python.org/pep-0704/. Again, you can opt-out if you want.
Re: One does not simply 'pip install'
#117Earlier quoted context omitted.
Building means downloading dependencies means an ever-growing module cache with no ability to prune it.
rm -rf ~/go once a year ought to do it
rm -rf ~/go is not recommended.
1. This will blow away any programs in ~/go/bin
2. Nothing in ~/go/pkg/mod has +w, so the rm -rf will not work anyway. Try
go clean -modcacheRe: One does not simply 'pip install'
#118Earlier quoted context omitted.
I think he prefers a python-esque way where they're sort of dumped in a flat namespace (and not in current project directory), rather than the node_modules way where it's recursively a copy of each thing and its specific exact dependencies, all the way down. There are ways to not use node_modules, by using newer Yarns for example.
> There are ways to not use node_modules, by using newer Yarns for example. My point was that if you use yarn2 in pmp mode, and you have a dependencies that depends on the node_modules layout being at the same level as package.json, than even if your package manager doesn't not need or use node_modules, it must emulate it so the dependencies can find their files.
[deleted]