While 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 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”
Agreed, using the paths makes it feel like a conventional toolchain. I haven’t tried this but it sounds like if I execute the python executable in the venv directory I get that shell. Only issue from there is writing executables that invoke the venv path in a deployable way
It isn't a mess: venv + pip is simple and (usually) sufficient.
Legacy/existing code or genuine justifications excepted, of course, there is no need to use anything else - even if an alternative is better, the use of alternatives is usually worse. Short of any massive technical reason, the best option is almost always to use the default option.
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.
Various packages rely on node_modules existing as a directory with a particular layout, some rely on being able to write into it. Some of the npm alternatives are built to store and manage dependencies in other ways (e.g., keep packages as zip files or other archives and get node to load direct from the zip), and these other mechanisms do not use a node_modules directory, hence compatibility problems.
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.
As a non-python person who has hair-pulling with python pip / pip3 / python2 / python3 python-is-python2-or-python3, this was a relevation.
pipenv looks like what pip should have been.
Another story on HN is "what happened to Ruby" and that really crystallized what I don't like about python. I'm not a ruby programmer, but I have to admit how much fantastic software came out of Ruby.
Ruby was always fighting Java for some reason, it should have been fighting Python. If only Ruby had won THAT war.
This is where npm gets it right. It's so much simpler to have the default install in a local folder, and then have an option to install globally if you like.