4 ms·

> One issue that I, now that you mention Javascript, is stuff like npm, but to me that more a sign of npm being badly broken by design, or at least designed for

> One issue that I, now that you mention Javascript, is stuff like npm, but to me that more a sign of npm being badly broken by design, or at least designed for a different environment. npm being "badly broken by design" is one opinion. But the fact is that almost all modern language tooling is moving in the direction of becoming more npm-like or has been created from the beginning with heavy npm inspiration. See for instance Rust's Cargo, Dart's Pub, Go's modules, Python's virtual env, Esy for Ocaml, and more. Developers love being able to easily manage and add dependencies, and this problem is only going to grow for Linux distributions across language ecosystems.

zozbot234 3y ago
What's "badly broken" is JavaScript development as a whole, and TypeScript provides the closest thing to a workable solution where library upgrades along semver lines can be expected to just work. Python is also a highly dynamic language, but there's also a lot less churn in that ecosystem and this does help to a large extent wrt. packaging libraries for a distribution.
mrweasel 3y ago
Pythons virtualenv is old than npm. For me, I think what makes Pythons dependency management work for me is that there's a logical separation between the environment and the package managers. You create a new environment, using venv, pyenv, Conda, containers, whatever you like, doesn't matter, then you install packages into that environment, might be latest, might be a specific version, depends entirely on your needs. Something like npm og Rubys Gem, are confusing because I have no idea where the packages went. Apparently they like somewhere in the current directory, maybe? What if I want to use the same environment and package elsewhere? I'm sure you can do it, but it doesn't seem logical to me that you don't need to specify which environment you're using. It's the same with Go, it's rather confusing where packages go, or which version, it's all squirreled away in the go command. In one way it is really nice that it just goes into the same project directory, but it's also a little confusing that your environment changes when you move directories. For production and containers... you normally just have that one thing running, so into the global environment it goes and here using apt to install the packages also ensures security updates, well not in the containers perhaps, unless you rebuild them.
- trey-jones 3y ago
  > It's the same with Go, it's rather confusing where packages go, or which version, it's all squirreled away in the go command Something that was lost when we moved to modules - the system is still the same, it's just that if you never used the old system (GOPATH) or read the manual, then you might be confused about where things have gone. Also of note is that vendoring was for a time Go's answer to dependency management and can still easily be done, and is supported by the tooling.
- pmontra 3y ago
  If you use Ruby with rvm or asdf the gems go in a directory inside your home, named after the ruby version you are using for a given project and possibly a gemset you defined, so two projects with different dependencies but the same ruby don't interfere with each other. Or just use bundle and activate only the gems in the local Gemfile. Or use docker and put everything inside a container. If I can complain about something is that there are so many ways to do it that I can't remember their details when I'm away from my laptop, as I am now. I think that I have at least one occurrence of all those 4 methods on my laptop, for different customers. They decide and everybody makes a different decision. Other languages: same problems with different tools.
- oblio 3y ago
  Or you could do the sane thing that Java/Maven did and have a classpath and have a single local repo and references just to stuff you need, without any conflicts (barring conflicts inherent to any package manager with transitive dependencies).
- lmm 3y ago
  > Something like npm og Rubys Gem, are confusing because I have no idea where the packages went. Apparently they like somewhere in the current directory, maybe? What if I want to use the same environment and package elsewhere? I'm sure you can do it, but it doesn't seem logical to me that you don't need to specify which environment you're using. I find the opposite - in theory the Python way might be more orthogonal, but in practice all that does is gives you more chance to shoot yourself in the foot. Realistically I never want to run project A's code in project B's environment or vice versa, and I certainly don't want to update project B's environment with project A's dependencies - combined with the fact that there's no way to undo a `pip install` command or recreate the previous state, you can permanently screw up your development environment by mixing up your terminals.

zozbot234 3y ago

What's "badly broken" is JavaScript development as a whole, and TypeScript provides the closest thing to a workable solution where library upgrades along semver lines can be expected to just work. Python is also a highly dynamic language, but there's also a lot less churn in that ecosystem and this does help to a large extent wrt. packaging libraries for a distribution.

mrweasel 3y ago

Pythons virtualenv is old than npm. For me, I think what makes Pythons dependency management work for me is that there's a logical separation between the environment and the package managers. You create a new environment, using venv, pyenv, Conda, containers, whatever you like, doesn't matter, then you install packages into that environment, might be latest, might be a specific version, depends entirely on your needs. Something like npm og Rubys Gem, are confusing because I have no idea where the packages went. Apparently they like somewhere in the current directory, maybe? What if I want to use the same environment and package elsewhere? I'm sure you can do it, but it doesn't seem logical to me that you don't need to specify which environment you're using. It's the same with Go, it's rather confusing where packages go, or which version, it's all squirreled away in the go command. In one way it is really nice that it just goes into the same project directory, but it's also a little confusing that your environment changes when you move directories. For production and containers... you normally just have that one thing running, so into the global environment it goes and here using apt to install the packages also ensures security updates, well not in the containers perhaps, unless you rebuild them.

trey-jones 3y ago
> It's the same with Go, it's rather confusing where packages go, or which version, it's all squirreled away in the go command Something that was lost when we moved to modules - the system is still the same, it's just that if you never used the old system (GOPATH) or read the manual, then you might be confused about where things have gone. Also of note is that vendoring was for a time Go's answer to dependency management and can still easily be done, and is supported by the tooling.
pmontra 3y ago
If you use Ruby with rvm or asdf the gems go in a directory inside your home, named after the ruby version you are using for a given project and possibly a gemset you defined, so two projects with different dependencies but the same ruby don't interfere with each other. Or just use bundle and activate only the gems in the local Gemfile. Or use docker and put everything inside a container. If I can complain about something is that there are so many ways to do it that I can't remember their details when I'm away from my laptop, as I am now. I think that I have at least one occurrence of all those 4 methods on my laptop, for different customers. They decide and everybody makes a different decision. Other languages: same problems with different tools.
oblio 3y ago
Or you could do the sane thing that Java/Maven did and have a classpath and have a single local repo and references just to stuff you need, without any conflicts (barring conflicts inherent to any package manager with transitive dependencies).
lmm 3y ago
> Something like npm og Rubys Gem, are confusing because I have no idea where the packages went. Apparently they like somewhere in the current directory, maybe? What if I want to use the same environment and package elsewhere? I'm sure you can do it, but it doesn't seem logical to me that you don't need to specify which environment you're using. I find the opposite - in theory the Python way might be more orthogonal, but in practice all that does is gives you more chance to shoot yourself in the foot. Realistically I never want to run project A's code in project B's environment or vice versa, and I certainly don't want to update project B's environment with project A's dependencies - combined with the fact that there's no way to undo a `pip install` command or recreate the previous state, you can permanently screw up your development environment by mixing up your terminals.