Hunting for Gems: How Ruby's package management system evolved(railsexplained.com) |
Hunting for Gems: How Ruby's package management system evolved(railsexplained.com) |
Specifically, bundler allows side-by-side version installs and the program simply loads the version specified in the bundle.lock thus making the lock file the source of truth where as npm, pip, even poetry install whatever version exists at the path. This pushes the source of truth from the .lock to that path.
It's not the end of the world, but when you're testing library versions side-by-side you can easily get confused whether you remembered to run `install` between the switches.
I'm surprised Python hasn't caught up to that. At best you can use Anaconda, but in order to have multiple versions of the same library, you end up having to create a new environment, which is another Python installation.
There are currently some nasty dependency issues caused by 3.11->3.12 breaking back compatibility in the standard library around the build system, alongside Numpy just kinda deciding semver doesn't matter between 1.20 and 2.0, that breaking changes don't warrant a major version bump if they tagged a deprecation warning on it. You just have to know their version scheme isn't really semver when pinning versions, which is lame of them, because ignoring that expectation has caused so many downstream breakages in the last couple of years.
So much could be solved if you could just say "this version of this package" in a dependency and not have to worry about compatibility on a completely different package
This can be done in the JS/TS world. It also occasionally breaks horribly in the JS/TS world. You might have multiple incompatible versions of a package in the tree when one dependency depends on one particular version, and the rest of your universe depends on another. It gets even worse when `Symbol`s come to play, since they'll be unique between those two versions.
It also doesn’t understand how to get packages from a git source.
From a release engineering perspective, this drives me batty.
It makes the pretty heavy assumption that a developer will always be able to bugfix the version differences.
Not sure what you mean.
Do you mean it uses whatever version exists in the path? I think that's a fair concern.
...or with `npm i git+ssh:...`, and npm will git clone it locally, as long as it has a `package.json`
You can install a certain commit, or even from a Gist!
In the npm-style dependency managers, generally speaking, you don’t really get dependency conflicts unless it’s a large overarching peer dependency or something like global singleton e.g. a GPU driver. Regardless of your thoughts on npm or having a massive number of tiny dependencies, you can’t deny npm dragged the dependency management field into the 21st century and forced it to scale.
for good reason. I strongly disagree that what you say is a good thing. you are describing a failure of the javascript ecosystem as a whole where pulling in a package for some trivial(leftpad) task is seen as a good thing and that having incompatible versions of them being able to be installed at the same time is a good thing instead of an indictment on the system. I stand by my statement that they have made the wrong decision at ever step.
The only problem I can really think of is working through issues when two gems require different irreconcilable versions of a library, and that's more of a fundamental ruby issue / design choice than a problem with bundler itself.
We had to pin our bundler to a specific version and it caused all sorts of issues when installing gems.
What you and I describe is not a bundler or npm problem so much that the software we are working on requires an outdated version of ruby and nodejs.
I agree with the the other comment though — npm has more problems even when with the latest version. Like Nodejs, it is flawed by design.