Speed would be nice, but more than that I want it to also manage Ruby installs. I’m infuriated at the mess of Rubys and version managers.

Hmmm. Aaron is cool, but also works at Shopify. Neither DHH nor Aaron mentioned anyone at the gem.coop project. I can't help but have mixed feelings here.

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

I wrote some code to do almost this many years ago (if I recall correctly, it doesn’t cache anything to disk, but builds the hash fresh each time, which can still result in massive speed up).

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)

https://github.com/pmahoney/fastup

For a "YAML" lockfile, you could probably write a much simpler and much more performant parser that throws out much of what makes YAML complicated, in particular, anchors, data type tags, all the ways of doing multi-line strings, all the weird unexpected type conversions (like yes/no converting to a boolean)... If the lockfile is never meant to be edited by human hands, only reviewed by human eyes, you can build a much simpler parser for something like:

  version: "1"
  dependencies:
    foo:
      version: "1.0"
      lock: "sha-blabla"

Although Yaml is a dreadful thing, given the context and the size of a normal gemspec I would be very surprised if it showed up in any significant capacity when psych should be in the low single digit MB/s throughput.

It mostly doesn't matter, because these metadata files are pulled into their respective package managers. When you publish to RubyGems the file is read into their database and made available to their API, just like when you publish a Python file the pyproject.toml is parse into the PyPI database and made available.

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.

What I would do to really squeeze the rest out in pure ruby (bear in mind I’ve been away about a decade so there _might be_ new bits but nothing meaningful as far as I know): Use a cheaper to parse index format (the gists I wrote years ago cover this: https://gist.github.com/raggi/4957402) Use threads for the initial archive downloads (this is just io, and you want to reuse some caches like the index) Use a few forks for the unpacking and post install steps (because these have unpredictable concurrency behaviors)

It's definitely not super straightforward, but there's plenty of recent prior art to steal from. Ruby was probably not the best place to solve this for the first time given the constraints (similar to pip), but there's no reason the Ruby ecosystem shouldn't now benefit from the work other ecosystems have done to solve it.

Do smart thing make code go brr? No. Stop do dumb thing make code go brr.

Rails 8.1 and ruby 3 are also very surprisingly fast, and coming back to an “omakase” framework is honestly a breath of fresh air especially now that with AI tools you can implement a lot of stuff from scratch instead of using deps.

I wouldn't say it stands out as being unusually slow, but it certainly isn't snappy.

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

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.

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

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.

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

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.

> Man, it's easy to be fast when you're wrong.

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.

When you're in a big company, the problem really starts showing. A service can have 100+ dependencies, many in private repos, and once you start adding and modifying dependencies, it has to figure out how to version it to create the lock file across all of these and it can be really slow.

Cloud dev environments can also take several minutes to set up.

Many of these package managers get invoked countless times per day (e.g., in CI to prepare an environment and run tests, while spinning up new dev/AI agent environments, etc).

There is no situation where toolchain improvements or workflow improvements should be snuffed at.

Must be nice not to use Python!

I agree for my own projects where the code and libraries are not enormous. The speed and size gains aren’t going to be something that matters enough.

try conda

took an hour to install 30 dependencies