Hacker News Reader

Comment by mark_l_watson | Hacker News Reader

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.

View on HN

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”

Once you create a venv, you can just refer to its path. I always disliked the whole activate/deactivate steps.

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

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

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 -modcache

> instead of the current venv + pip mess

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.

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.

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.

> these other mechanisms do not use a node_modules directory,

Once you've landed on a package manager that does use it, wouldn't you continue to use that?

It doesn't matter if you decide to use a different package manager, if one of your dependencies depend on that layout, you must supply that layout.

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.

How is npm any saner?

Last week I've had one colleague complain about his brokem npm install. He had to manually install each module and it's exact version.

A month before that, we had one broken old nodejs project which couldn't update itself cleanly.

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.

Reply on news.ycombinator.com