5 ms·

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

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.

galleywest200 4y ago
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...
- nicoburns 4y ago
  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”
  - mejutoco 4y ago
    Once you create a venv, you can just refer to its path. I always disliked the whole activate/deactivate steps.
    - Aurelius108 4y ago
      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
- ilyt 4y ago
  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.
  - Groxx 4y ago
    Building means downloading dependencies means an ever-growing module cache with no ability to prune it.
    - ilyt 4y ago
      rm -rf ~/go once a year ought to do it
      - sigjuice 4y ago
        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
georgyo 4y ago
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.
- michaelcampbell 4y ago
  > 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.
  - llanowarelves 4y ago
    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.
    - georgyo 4y ago
      > 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 4y ago
        [deleted]
  - azornathogron 4y ago
    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.
wheelerof4te 4y ago
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.
kcartlidge 4y ago
> 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.

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.

galleywest200 4y ago

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

nicoburns 4y ago
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”
- mejutoco 4y ago
  Once you create a venv, you can just refer to its path. I always disliked the whole activate/deactivate steps.
  - Aurelius108 4y ago
    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
ilyt 4y ago
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.
- Groxx 4y ago
  Building means downloading dependencies means an ever-growing module cache with no ability to prune it.
  - ilyt 4y ago
    rm -rf ~/go once a year ought to do it
    - sigjuice 4y ago
      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

georgyo 4y ago

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.

michaelcampbell 4y ago
> 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.
- llanowarelves 4y ago
  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.
  - georgyo 4y ago
    > 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 4y ago
      [deleted]
- azornathogron 4y ago
  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.

wheelerof4te 4y ago

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.

kcartlidge 4y ago

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