Can Bundler be as fast as uv?
tenderlovemaking.com
tenderlovemaking.com
> Ignoring requires-python upper bounds. When a package says it requires python<4.0, uv ignores the upper bound and only checks the lower. This reduces resolver backtracking dramatically since upper bounds are almost always wrong.
I don't think that ignoring upper bounds has a significant impact on uv's performance. We do this for a totally different reason, which is that it leads to better solves. For example, if you say your project requires Python 3.8 or later, but some dependency said it works for ">=3.8,<4", then suddenly your project isn't installable on Python 4, and you'd be implicitly required to put a "<4" bound on your own project. uv solves for all of your supported Python versions, not a single version, so discounting the upper bounds doesn't actually save us any time in the solve.
(See, e.g. https://discuss.python.org/t/requires-python-upper-limits/12....)
So you can run
uv run poe docs
Instead of
uv run sphinx-build -W -b dirhtml docs/source docs/build
Many languages have a task runners baked into their package manager, but many others don’t. In Ruby it’s roughly the equivalent of Rake.
> mise can be used as a drop-in replacement for asdf. It supports the same .tool-versions files that you may have used with asdf and can use asdf plugins through the asdf backend.
> It will not, however, reuse existing asdf directories (so you'll need to either reinstall them or move them), and 100% compatibility is not a design goal. That said, if you're coming from asdf-bash (0.15 and below), mise actually has fewer breaking changes than asdf-go (0.16 and above) despite 100% compatibility not being a design goal of mise.
> Casual users coming from asdf have generally found mise to just be a faster, easier to use asdf.
I never understood the real need for chruby rvm etc... - I manage everything, all programs, in a versioned AppDir manner. (Note: I am not using GoboLinux; I use a modified variant. GoboLinux gave the correct idea though.)
> each program in a GoboLinux system has its own subdirectory tree, where all of its files (including settings specific for that program) may be found. Thus, a program "Foo" has all of its specific files and libraries in /Programs/Foo, under the corresponding version of this program at hand. For example, the commonly known GCC compiler suite version 8.1.0, would reside under the directory /Programs/GCC/8.1.0
It's not really that easy being really different in the Linux packaging world.
I can relate to the "I wish we didn't need a second tool", but it doesn't seem like much of a mess.
If python version changes in an uv-managed project, you don't have to do any extra step, just run "uv sync" as you normally do when you want to install updated dependencies. uv automatically detects it needs a new python, downloads it, re-creates the virtual environment with it and installs the deps all in one command.
And since it's the command which everyone does anytime a dependency update is required, no dev is gonna panic why the app is not working after we merge in some new code which requires newer python cause he missed the python update memo.
At this point I've used rbenv, rvm, asdf, mise, and one other whose name isn't coming to mind. Not to mention docker containers, with or without any of those tools.
I don't mean to project any particular complaint onto you, and I'm curious what part of it is infuriating? Each of the version managers I've used has functioned as advertised, and I'm able to get back to work pretty smoothly.
One challenge, as I see it, is that there are three kinds of Ruby projects that need to take different approaches to the matter, in increasing level of complexity:
(1) Developing a longer-lived, deployed or distributed project. Here you should definitely use both the Gemfile Ruby version and a .ruby-version file. You're normally only targeting one version at a time, but contributors and/or users are very unlikely to somehow accidentally end up using the wrong Ruby version without getting a very obvious notification that they are using the wrong Ruby version. That's annoying to encounter, but not difficult to solve once you know that the concept of a "version manager" exists.
(2) Hacking on your own small project or just banging out a script. You just want to run some Ruby version and get to it. You probably should default to the latest, unless there's some dependency requiring a lower version, and you might not know that until after you've gotten started. The inverse issue might also occur, e.g. you installed Ruby 3.1 a few years ago, you start hacking, and now you want to pull in a gem version that requires Ruby 3.4. You can manage this by putting the Ruby version in your Gemfile, or using a .ruby-version file, or both, but if you're relatively green and just diving in, this might not be on your radar.
(3) Developing a gem. You probably want to test/validate your gem across multiple Ruby versions, and possibly even different versions of your dependencies. You obviously don't want to lock yourself into a single Ruby version, and use of a .ruby-version file is inappropriate. There is tooling to do this, but it takes some learning to be able to utilize.
My belief is that it is worth it for install documentation for category (1) to be a little more explicit about how to get up and running. For category (2), I don't know what the right answer is, but I understand the potential pain points.
What I was most curious about is whether AlphaSite's complaint was with a specific version manager, or the fact that multiple options for version managers exist, or even the need for version managers at all?
I think all of ruby, including the ecosystem as well as how ruby is governed, needs to be considered. In particular with ruby constantly declining and losing user share. That is not good. That should change.
I think the underlying issue is much bigger than merely contained on speed. It also has to do with control - both for developers as well as users.
This is also why I think the label "prematurely" is weird, because it attempts to singularize everything down to the speed label. I think the issue is much wider than what is faster. In fact, speed doesn't interest me that much; whether it takes 0.35 seconds or 0.45 seconds or even 1.5 seconds to install a gem, is just so irrelevant to me. But, for instance, high quality documentation - now that is an area where ruby failed in epic ways. Not all projects but many. And then ruby wonders why it is dying? And nobody wants to focus on these issues really. So the issue should really be viewed much larger in scope than "merely" "speed is the issue". I mean ... matz focused on speed in the last 10 years. Ok. Ruby declined. Well, perhaps it is time to focus on other things more - not that people mind a faster ruby, but if a language is dying, then you need to think really hard, come up with a plan, multiple ideas, and push these hard. Rather than, say, purge away old developers and claim nothing happened here and all is well ...
Python has ML. JS has web. C/C++ has performance. Rust is stealing a slice of that thanks to safety.
That probably covers like 99% of things, at least from my world view. There are arguably other better languages but it doesn't much matter if the community all flocks to the well established ones.
Ruby used to be cool around 2010, but it lost to better options. Ruby has strange syntax, and Rails abuses magic, so I guess the viability of TypeScript for development made Ruby less popular.
I'd argue that it lost the cool kidz mindshare but not to better options. People jumped to Node.js because of async but in the end the relevant industry change was the switch to SPA based architectures in the web space. Rails never embraced that approach and hence lost the popularity.
Jump 15 years ahead, and now the Enterprise world is built with React and Angular apps, not with JSPs or Spring MVC apps. Can Rails do a comeback? Who knows, but it's still a bona fide web development stack with terrific productivity gains for those who want to optimize that metric.
Give it a rest.
> Fortunately RubyGems.org already provides the same information about gems.
> [...]
> After we unpack the gem, we can discover whether the gem is a native extension or not.
Why not adding the meta information of whether the gem is a native extension or not directly to rubygems.org? You could fully parallelize whole installation trees of dependencies then.
From working on RubyGems.org a long time ago I vaguely remember that the metadata extracted from the gemspec is version-specific. So if you add a new native_extension boolean you'd have to artificially reprocess those previously published gemspecs to change the metadata for all past versions.
Being able to mutate metadata for past versions is dangerous enough that I'd be surprised it's allowed or even possible. So that might not even be something Aaron considered here for that reason. That said, it seems reasonable to me to suggest this improvement going forward to make unpacking the gem unnecessary to know whether it'll affect installation order.
How uv got so fast - https://news.ycombinator.com/item?id=46393992 - Dec 2025 (457 comments)
That would mean that if you edited your gems directly, things would break. Add a file, and it wouldn't get found until the metadata got rehashed. The gem install, uninstall, etc commands would need to be modified to maintain that metadata. But really, you shouldn't be hacking up your gem library like that ith shellcommands anyway (and if you are doing manual surgery, having to regen the metadata isn't really that burdensome).
Probably obsolete and broken by now, but one of my favorite mini projects.
(And I just realized the graph is all but impossible to read in dark mode)
But in general, one of the biggest problems with Ruby for me is how $LOAD_PATH causes combinatoric explosion when you add gems because every gem is added, due to the lack of any scoping of require's to packages.
The existence of multiple projects to cache this is an illustration that this is a real issue. I've had project in the past where starting the app took minutes purely due to require's, and where we shaved minutes off by crude manipulation of the load path, as most of that time was pointless stat calls.
And yes I proposed to integrate bootsnap into bundler ages ago, but got told to go away.
Ruby Gems are tar files, and one of the files in the tar file is a YAML representation of the GemSpec. This YAML file declares all dependencies for the Gem, so RubyGems can know, without evaling anything, what dependencies it needs to install before it can install any particular Gem. Additionally, RubyGems.org provides an API for asking about dependency information, which is actually the normal way of getting dependency info (again, no eval required).
That said, the points at the end about not needing to parse gemspecs to install "most" dependencies would make this pretty moot (if the information is already returned from the gemserver)
This is a major reason why UV is faster than older python package managers, as they were able to take advantage of the change in the PyPI registry that enabled this. Now these package managers can run their dependency calculations without needing to download the entire package, decompress the package files, and then parse them.
version: "1"
dependencies:
foo:
version: "1.0"
lock: "sha-blabla"If you didn't need backwards compatibility with older rubies you could use Ractors in lieu of forks and not have to IPC between the two and have cleaner communication channels. I can peg all the cores on my machine with a simple Ractor pool doing simple computation, which feels like a miracle as a Ruby old head. Bundler could get away with creating their own Ractor safe installer pool which would be cool as it'd be the first large scale use of Ractors that I know of.
It’s interesting as a target because it pays off more the longer it has been implemented as it only would be shared from versions going forward.
> Ignoring requires-python upper bounds. When a package says it requires python<4.0, uv ignores the upper bound and only checks the lower. This reduces resolver backtracking dramatically since upper bounds are almost always wrong. Packages declare python<4.0 because they haven’t tested on Python 4, not because they’ll actually break. The constraint is defensive, not predictive
Man, it's easy to be fast when you're wrong. But of course it is fast because Rust not because it just skips the hard parts of dependency constraint solving and hopes people don't notice.
> When multiple package indexes are configured, pip checks all of them. uv picks from the first index that has the package, stopping there. This prevents dependency confusion attacks and avoids extra network requests.
Ambiguity detection is important.
> uv ignores pip’s configuration files entirely. No parsing, no environment variable lookups, no inheritance from system-wide and per-user locations.
Stuff like this sense unlikely to contribute to overall runtime, but it does decrease flexibility.
> No bytecode compilation by default. pip compiles .py files to .pyc during installation. uv skips this step, shaving time off every install.
... thus shifting the bytecode compilation burden to first startup after install. You're still paying for the bytecode compilation (and it's serialized, so you're actually spending more time), but you don't associate the time with your package manager.
I mean, sure, avoiding tons of Python subprocesses helps, but in our bold new free threaded world, we don't have to spawn so many subprocesses.
There's never going to be a Python 4 so I don't think they are wrong. Even if lighting strikes thrice there's no way they could migrate people to Python 4 before uv could be updated to "fix" that.
> Ambiguity detection is important.
I'm not sure what you mean here. Pip doesn't detect any ambiguities. In fact Pip's behaviour is a gaping security hole that they've refused to fix, and as far as I know the only way to avoid it is to use `uv` (or register all of your internal company package names on PyPI which nobody wants to do).
> thus shifting the bytecode compilation burden to first startup after install
Which is a much better option.
There will, but called Pyku ...
Agreed the current behavior is stupid, FWIW. I hope PEPs 708 and 752 get implemented soon. I'm just pointing out that there's an important qualitative difference between
1. we do the same job, but much faster; and
2. we decided your job is stupid and so don't do it, realizing speedups.
uv presents itself as #1 but is actually #2, and that's a shame.
“If a tree falls in the forest…”
Stuff like this sense unlikely to contribute to overall runtime, but it does decrease flexibility.
Astral have been very clear that they have no intention of replicating all of pip. uv pip install was a way to smooth the transition from using pip to using uv. The point of uv wasn't to rewrite pip in rust - and thankfully so. For all of the good that pip did it has shortcomings which only a new package manager turned out capable of solving.
> No bytecode compilation by default. pip compiles .py files to .pyc during installation. uv skips this step, shaving time off every install.
... thus shifting the bytecode compilation burden to first startup after install. You're still paying for the bytecode compilation (and it's serialized, so you're actually spending more time), but you don't associate the time with your package manager.
In most cases this will have no noticeable impact (so a sane default) - but when it does count you simply turn on --compile-bytecode.
You could argue that uv has a better default behavior than pip, but that's not an engineering advantage: it's just a different choice of default setting. If you turned off eager bytecode compilation in pip you'd get the same result.
Until pip does make the change, this is an engineering advantage for uv. Engineers working on code are part of the product. If I build a car with square wheels and don't change them when I notice the issue, my car still has a bumpy ride, that's a fact.
Version bound checking is NP complete but becomes tractable by dropping the upper bound constraint. Russ Cox researched version selection in 2016 and described the problem in his "Version SAT" blog post (https://research.swtch.com/version-sat). This research is what informed Go's Minimal Version Selection (https://research.swtch.com/vgo-mvs) for modules.
It appears to me that uv is walking the same path. If most developers don't care about upper bounds and we can avoid expensive algorithms that may never converge, then dropping upper bound support is reasonable. And if uv becomes popular, then it'll be a sign that perhaps Python's ecosystem as a whole will drop package version upper bounds.
1. solve dependency constraints as if upper bounds were absent,
2. check that your solution actually satisfies constraints (O(N), quick and passes almost all the time), and then
3. only if the upper bound constraint check fails, fall back to the slower and reliable parser.
This approach would be clever, efficient, and correct. What you don't get to do is just ignore the fucking rules to which another system studiously adheres then claim you're faster than that system.
That's called cheating.
While I agree that an optimistic optimization for the upper-bound-pass case makes sense, just ignoring the bounds just isn't correct either.
Common pattern in insurgent software is to violate a specification, demonstrate speedups, and then compare yourself favorably to older software that implements the spec (however stupid) faithfully.
If you can consistently do that, then it IS the correct thing to do.
uv made that choice and users use them, is there an objective truth of what is “correct” to do version parsing?
What's underhanded about this? What are the observable effects of this choice that make it wrong? They reformulated the a problem into a different problem that they could solve faster, and then solved that, and got away with it. Sounds like creative problem solving to me.
We ignore upper bounds because it leads to a better solve. You can read my comment here: https://news.ycombinator.com/item?id=46464453. There's significant discussion about this, e.g., here: https://discuss.python.org/t/requires-python-upper-limits/12....
> Ambiguity detection is important.
I think you're misunderstanding why we do this: it's a security feature. pip's design is inherently vulnerable to dependency confusion attacks, since packages of the same name across indexes are considered equally trusted by pip. You can look up the torchtriton attack to learn more.
> Stuff like this sense unlikely to contribute to overall runtime, but it does decrease flexibility.
I think you're misinformed. We support all of these features: system- and per-user configuration files, environment variables, etc. We just don't read _pip's_ configuration file, which is intended for pip, not uv.
Compiler, yes. Linker, sure. Package downloader. No.
The reason for speeding up bundler isn't CI, it's newcomer experience. `bundle install` is the overwhelming majority of the duration of `rails new`.
I’d wager the majority of CI usage fits your bill of “terrible”. No provider provides OOTB caching in my experience, and I’ve worked with multiple in house providers, Jenkins, teamcity, GHA, buildkite.
Buildkite can be used in tons of different ways, but it's common to use it with docker and build a docker image with a layer dedicated to the gems (e.g. COPY Gemfile Gemfile.lock; RUN bundle install), effectively caching dependencies.
Caching is a great word - it only means what we want it to mean. My experience with GHA default caches is that it’s absolutely dog slow.
> Buildkite can be used in tons of different ways, but it's common to use it with docker and build a docker image with a layer dedicated to the gems (e.g. COPY Gemfile Gemfile.lock; RUN bundle install), effectively caching dependencies.
The only way docker caching works is if you have a persistent host. That’s certainly not most setups. It can be done, but if you have that running in docker doesn’t gain you much at all you’d see the same caching speed up if you just ran it on the host machine directly.
GHA is definitely far from the best, but it works:, e.g 1.4 seconds to restore 27 dependencies https://github.com/redis-rb/redis-client/actions/runs/205191...
> The only way docker caching works is if you have a persistent host.
You can pull the cache when the build host spawns, but yes, if you want to build efficiently, you can't use ephemeral builders.
But overall that discussion isn't very interesting because Buildkite is more a kit to build a CI than a CI, so it's on you to figure out caching.
So I'll just reiterate my main point: a CI system must provide a workable caching mechanism if it want to be both snappy and reliable.
I've worked for over a decade on one of the biggest Rails application in existence, and restoring the 800ish gems from cache was a matter of a handful of seconds. And when rubygems.org had to yank a critical gem for copyright reasons [0], we continued building and shipping without disruption while other companies with bad CIs were all sitting ducks for multiple days.
The problem is that none of the providers really do this out of the box. GHA kind of does it, but unless you run the runners yourself you’re still pulling it from somewhere remotely.
> I've worked for over a decade on one of the biggest Rails application in existence, and restoring the 800ish gems from cache was a matter of a handful of seconds.
I kind of suspected - the vast majority of orgs don’t have a team of people who can run this kind of a system. Most places with 10-20 devs (which was roughly the size of the team that ran the builds at our last org) have some sort of script, running on cheap as hell runners and they’re not running mirrors and baking base images on dependency changes.
CircleCI does. And I'm sure many others.
For reference, oven-sh/setup-bun opted to install dependencies from scratch over using GHA caching since the latter was somehow slower.
https://github.com/oven-sh/setup-bun/issues/14#issuecomment-...
Cloud dev environments can also take several minutes to set up.
But in public tooling, where the benefit is across tens of thousands or more? It's basically always worth it.
Like, I switched my team's docker builds to Depot and we immediately halved our CI costs and shed like 60% of the build time because it's a persistent worker node that doesn't have to re-download everything every time. I have no association with them, just a happy customer; I'm only giving it to illustrate how many more gains are typically on the table before a few seconds here and there are the next thing to seriously put effort into.
took an hour to install 30 dependencies