Hunting for Gems: How Ruby's package management system evolved
railsexplained.com
Hunting for Gems: How Ruby's package management system evolved
1–10 of 22 posts
Re: Hunting for Gems: How Ruby's package management system evolved
#2They still don't have cryptographic signatures widely signing gems despite deploying optional infrastructure to do it. What a waste and sad.
Re: Hunting for Gems: How Ruby's package management system evolved
#3FWIW, I LOVE bundler and it absolutely kills me that npm, pip still haven't settled well in to the management of it.
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.
Re: Hunting for Gems: How Ruby's package management system evolved
#4FWIW, I LOVE bundler and it absolutely kills me that npm, pip still haven't settled well in to the management of it. 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 th…
It’s even worse when npm install modifies the package lock file.
It also doesn’t understand how to get packages from a git source.
From a release engineering perspective, this drives me batty.
Re: Hunting for Gems: How Ruby's package management system evolved
#5FWIW, I LOVE bundler and it absolutely kills me that npm, pip still haven't settled well in to the management of it. 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 th…
It’s even worse when npm install modifies the package lock file. It also doesn’t understand how to get packages from a git source. From a release engineering perspective, this drives me batty.
> It also doesn’t understand how to get packages from a git source.
Not sure what you mean.
Re: Hunting for Gems: How Ruby's package management system evolved
#6Earlier quoted context omitted.
It’s even worse when npm install modifies the package lock file. It also doesn’t understand how to get packages from a git source. From a release engineering perspective, this drives me batty.
> It also doesn’t understand how to get packages from a git source. Not sure what you mean. https://bundler.io/guides/git.html
He's talking about npm
Re: Hunting for Gems: How Ruby's package management system evolved
#7FWIW, I LOVE bundler and it absolutely kills me that npm, pip still haven't settled well in to the management of it. 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 th…
It’s even worse when npm install modifies the package lock file. It also doesn’t understand how to get packages from a git source. From a release engineering perspective, this drives me batty.
i’ve said before that it’s like the npm people have made the worst possible design choice whenever asked for a decision. it’s insane how bad it is compared to bundler or comparable package management tools.
Re: Hunting for Gems: How Ruby's package management system evolved
#8FWIW, I LOVE bundler and it absolutely kills me that npm, pip still haven't settled well in to the management of it. 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 th…
It’s even worse when npm install modifies the package lock file. It also doesn’t understand how to get packages from a git source. From a release engineering perspective, this drives me batty.
As I understand it, the idea is that npm install is what's used during development, while npm ci/clean-install is what you use for deployments and your CI system.
It makes the pretty heavy assumption that a developer will always be able to bugfix the version differences.
Re: Hunting for Gems: How Ruby's package management system evolved
#9Earlier quoted context omitted.
It’s even worse when npm install modifies the package lock file. It also doesn’t understand how to get packages from a git source. From a release engineering perspective, this drives me batty.
i’ve said before that it’s like the npm people have made the worst possible design choice whenever asked for a decision. it’s insane how bad it is compared to bundler or comparable package management tools.
No, I strongly disagree. Npm may have some weird ergonomics and defaults, but as a dependency manager it is first class. Before npm, almost all dependency managers suffered from the diamond dependency problem. Npm pioneered allowing multiple versions of packages to be simultaneously installed without having to chase down conflicting dependencies as long as the package involved is not a major framework (i.e. peer dependency). For example you can’t (or at least strongly discouraged to) have react v15 and react v20 in the same project, but you can have leftpad v1 and leftpad v3 in the same project. You cannot do this in most other languages like Ruby Python Dart C++ etc. (Java has a similar but half baked concept called shading which requires a separate plugin) Go and Rust followed what npm pioneered, allowing multiple conflicting dependencies too, saving countless hours of developer time. Rust goes as far as supporting linking against code from different language versions. Without npm, Cargo would be doing NP class dependency searches and Rust developers would be wasting forking old upstream repos to bring them up to date. Not everybody has the engineering resources of google to build everything in house and keep every single dependency in sync through a massive monorepo and test suite.
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.
Re: Hunting for Gems: How Ruby's package management system evolved
#10FWIW, I LOVE bundler and it absolutely kills me that npm, pip still haven't settled well in to the management of it. 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 th…
> Specifically, bundler allows side-by-side version installs and the program simply loads the version specified in the bundle.lock
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