To talk about what Ruby Central is doing now, we need to start with a bit of historical context. What was Ruby Central doing before this saga began? About 18 months ago, Ruby Central:
Then, about 10 months ago, Ruby Central began what core team member Ellen Dash called a “hostile takeover” of the RubyGems, Bundler, and RubyGems.org open source projects, seizing control of the projects and locking out the team that had nurtured and maintained them for over a decade.
Today, 10 months after their takeover, Ruby Central has:
Unlike many community non-profits (including the Python Software Foundation), Ruby Central does not hold elections for their board of directors. Despite rewriting their bylaws entirely this year, new directors are still selected exclusively by existing directors, with no public process for input or feedback. The current board consists of just 2 of the 7 members who initially approved the hostile takeover, plus 3 new members chosen by the previous board (Brandon, Jey, and Ran).
Based on Ruby Central’s public announcements, they have added exactly one new program after ending both conferences and transferring away half of their open source software: a new security project, funded by a grant from Alpha-Omega. The security project’s goal is to use Anthropic’s Project Glasswing to search for security issues in gems that have already been published. In their first monthly report for June, they reported finding a total of 5 vulnerabilities, with 1 issue at medium severity, and 4 at low or unclassified severities.
Ruby Central’s current sponsorship drive, the Ruby Alliance, has found three members willing to join: Gusto, Thoughtbot, and (very recently) Shopify. What none of the sponsorship announcement posts have mentioned is that Gusto and Thoughtbot employ two of the five Ruby Central board members. David Corson-Knowles is both a board member and a Senior Staff Engineer at Gusto. Ran Craycraft is not just President of the Ruby Central board, he is also Managing Director, Americas at Thoughtbot. That means the board members who allocate the sponsorship money are also providing that sponsorship money, a conflict of interest which neither the companies nor Ruby Central have disclosed. The final sponsor is Shopify, coming back 9 months after it was reported they demanded Ruby Central start this disaster in the first place.
No, our dispute has not been resolved. Since last October, Ruby Central has been threatening to sue me. They have not withdrawn that threat as of today.
The core of our dispute is that last September, Ruby Central hijacked the Bundler and RubyGems GitHub projects from their maintainers of over ten years. When I informed Ruby Central that I own the name Bundler, they retaliated with a threat to sue me for supposed “hacking”, a position I have always disputed.
Ruby Central has stated they will only withdraw their threat if I drop my claim they infringed the name Bundler. After I also questioned if my work as a contractor had been allowed by state labor law, they additionally started demanding that I drop any claims regarding employment as well. So far, Ruby Central has consistently said they will only withdraw their lawsuit threat if I give up my infringement claim for Bundler and any possible back pay I believe they owe me.
When the lawsuit threat did not make me drop my claims, Ruby Central then chose to give away the Bundler gem and rubygems GitHub repo to Matz. After that, all of the former maintainers made a new offer to settle. Ruby Central never replied to our offer. Instead, they restated their original offer, and only to me: they would withdraw their threat to sue only if I dropped all of my claims. I did not accept, and after four months with no further progress, I wrote a public update.
In response to my post, Ruby Central did two things at once:
First, Ruby Central told me they were actively seeking outside funding to pay a settlement to me that would end our dispute. They asked me for an amount that would fully compensate me for my attorney’s fees, the amount they might owe in back pay, plus compensation for an additional six months after I was fired. With help from an expert, I calculated an amount around $450,000, and provided that number as requested.
Despite providing that number, I have never asked for that amount of money. I provided that number at Ruby Central’s request, so they could seek funding. What I have instead asked for, consistently, is an apology for the attacks on my reputation without evidence, and the far smaller amount of reimbursement for my attorneys’ fees.
Second, at the same time as they sought funding for a settlement, Ruby Central also reported me to the FBI through their lawyer, requesting that I be criminally investigated. On March 9, 2026, Ruby Central’s lawyer informed my lawyer that he had made the report, and suggested I would need to hire a criminal defense attorney. As far as I have been able to learn, Ruby Central’s lawyer was not able to provide any evidence to the FBI with his report, since Ruby Central has not been able to find evidence that I caused any harm during their three audits of the RubyGems AWS account.
Unfortunately, it is impossible to withdraw a report to the FBI. Despite Ruby Central’s later statement to me that they don’t intend to pursue the FBI report, they gave up the ability to make that decision when they filed the report — it’s up to the FBI now, not up to them.
A few weeks after saddling me with a permanent possibility of criminal prosecution by the FBI, Ruby Central ran out of money. Their post said they “want to move forward together”, but did not take any action or answer any questions regarding their past actions. Nonetheless taking that post as a promising sign, I offered Ruby Central a new option to resolve our disagreement.
I did not ask them to return Bundler. I did not ask them for fair payment under employment law. I didn’t even ask for an apology. Instead, I asked for 1) public confirmation that I did not cause any harm to RubyGems, and 2) reimbursement for the lawyer fees I have had to pay because of their threatened lawsuit. Ruby Central then ignored that post, and multiple attempts to reach out, for six weeks.
After six weeks, Ruby Central sent me a rerun of their settlement offer, with some specific restrictions: they would withdraw their lawsuit threat if I drop my claim they infringed the Bundler trademark, drop my claim they violated employment law, and agree to non-disparagement that binds me but does not bind Ruby Central, instead only specific individuals currently associated with them.
This offer did contain one new twist. Ruby Central wrote that if I accepted they would limit their cooperation with the FBI, offering to “discourage the filing of criminal charges, and if an investigation is opened or charges filed, cooperate only to the extent required by law”. There’s just one small problem with that offer: many state and federal laws make it a crime to agree to any limits on cooperation with a criminal investigation. Needless to say, I could not accept such a settlement.
Since Ruby Central can’t withdraw their FBI report (because it’s out of their hands now), and they can’t give back the repos they took (because they don’t have them anymore), and they can’t pay any kind of compensation (because they don’t have any money), I was at a bit of a loss. What could Ruby Central even do to try to resolve this situation that they had created?
In the end, I responded with a counter-offer of my own: I would drop my infringement claim against Ruby Central over their use of the name Bundler, and I would drop my claim Ruby Central violated employment law, if they would withdraw their threat to sue me and publish an apology. I asked them to apologize for publicly accusing me of harming RubyGems.org without evidence, apologize for claiming I tried to obtain user PII when I did not, and apologize for breaking the Bundler and RubyGems governance to execute their takeover. Surprising me, Ruby Central did not object to the apology I requested.
Unfortunately, Ruby Central has continued to insist on a non-disparagement agreement that binds me, but does not bind Ruby Central. I was forced to reply that I could not accept such an unbalanced agreement.
It has been 30 days since my counter-offer. While RubyConf did take up 3 of those days, Ruby Central has not replied for the full 30 days. Their lawyer promised to provide a timeframe for their response within one day, and has not done even that. A month with no response points to a different kind of resolution: an incredibly disappointing legacy for the shattered remains of a once-legendary organization.
Even after all of the consequences described here, Ruby Central has never acknowledged that maintainers of over ten years should not have been thrown out of their own projects. Ruby Central either does not know, or is not willing to admit, that they needlessly attacked and removed the existing team when we could have given them all the help they needed to secure their systems. Ruby Central’s public posts to date carefully offer no apologies to the maintainers.
The sole public justification they have ever offered for this hostile takeover is that they did this “to improve security”. Unfortunately, Ruby Central removed all of the experts who could have ensured they executed their takeover securely. When I responsibly disclosed Ruby Central’s failure to secure their systems, which embarrassed them, they retaliated by publicly accusing me of “hacking” and privately preparing to sue me.
As of this writing, Ruby Central has conducted no less than three separate audits, seeking evidence that I caused some sort of harm. They have not found any evidence, because (beyond revealing Ruby Central’s embarrassing failure to secure the RubyGems.org service) I did not take, damage, or harm any part the RubyGems.org service.
During the multiple months where Ruby Central ignored my offers to settle, after baselessly reporting me to the FBI, they nevertheless published a “Fracture Incident Report”, which states it was written to “provide closure”. Unfortunately for that closure, the report does not explain any of the reasons Ruby Central chose a path that destroyed their sponsorships, their volunteers, their open source projects, their staff, and their board of directors.
For example, what actions did the board actually vote to approve? What did Ruby Central expect to gain? Why did Ruby Central single me out personally, while ignoring the other maintainers? Why jump straight from being embarrassed to threatening a lawsuit? What could possibly justify involving the FBI while there is no evidence of any harm? The report answers none of these questions.
Instead, Ruby Central continues former Executive Director Shan Cureton’s public policy, even beyond her departure: no one deserves to know why any of this happened, because “they don’t need to have the story, and it isn’t their story to have”. According to Ruby Central, I don’t deserve to know why this happened, none of the former maintainers deserve to know why this happened, and no one else in the Ruby community deserves to know why this happened. Including you.
There was a time when Ruby Central did more work to support the Ruby community than any other organization in the United States. In 2004, when I first started learning Ruby, I was surprised to discover that RubyConf 2005 would be in San Diego, close enough for me to attend. I rounded up my only two friends who also liked programming, and we went together.
I saw Matz give a talk proposing the -> “stabby lambda” syntax. I tried to understand call_cc in a talk given by Jim Weirich using a Nintendo 64 to demonstrate continuations via The Legend of Zelda: Ocarina of Time. I saw the Rails core team, working toward releasing Rails 1.0 in December of that year. I joined IRC on Freenode, where I made a huge number of Ruby friends I still have today, over 20 years later. I met other students who were attending from nearby UCSD, and we are also still friends to this day.
Just over a year later, I attended the first RailsConf in 2006. I met some strangers, we became friends, and one of them invited me to apply to work at his company. That became my first full-time job, set an unrealistically high standard for managers and co-workers, and made me even more friends that I still talk to regularly today.
Ruby Central’s conferences changed my life, in the best way possible. The community that grew out of the events, talks, online chats, and shared code inspired me to contribute back — to help create and ship Bundler 1.0 in 2009, to maintain Bundler for the next 15 years, to work on RubyGems and RubyGems.org for over 10 years, and to found the non-profit Ruby Together to focus on funding and maintenance for 7 years.
When Ruby Central reached out to express interest in merging with Ruby Together, and combining my open source programs with their conference programs, I was flattered. I agreed to the merger based on their spectacular track record of conferences and community-building from 2001 to 2021.
It’s incredibly sad that today, just a few years later, Ruby Central has zero upcoming conferences for the first time in their 25 year existence. It’s even more sad that this entire dispute, far from strengthening Ruby Central as they claimed to want, has instead attacked the very community governance they were supposed to be providing.
Even beyond getting thrown out of the project that I helped create, after fundraising for a decade to keep it alive, Ruby Central’s betrayal of the community hurts. It hurts to see not just me, but a whole team of maintainers driven away from the projects they have nurtured and developed for so many years. It hurts to hear that even after all of this, it was done for no real reason anyone can explain, and produced no real benefits that anyone can point at. That’s no way to rebuild trust, or to support and grow a community.
The Ruby community deserves better.
We can create open source projects governed openly by their maintainers, like gem.coop. We can build new tools that make using Ruby better for everyone, like rv or Ruby Butler. While I have no interest in creating any more Ruby non-profits, I hope one day there will be Ruby community organizations where the directors are elected by the community, perhaps like the Python Software Foundation board.
We can’t return to the past, when Ruby Central’s conferences were popular and amazing community events, and when Ruby Together supported open source projects without claiming to own them. Instead of spending our time trying to bring back the old days, let’s work together to build Ruby a brighter future.
]]>]]>jj improves upon Git by achieving two opposing goals at the same time: it has a simpler mental model and command set, but simultaneously provides more powerful functionality. jj simplifies Git not by hiding complexity, but by using a better conceptual model.
Head over to the Spinel Cooperative blog to read Meet Spinel.
]]>jj’s whole deal is that it collapses many Git concepts (stashes, staging, fixups, in-progress rebases, conflicts) into a single unified model of working with history, which then lets you use the same tools to do all of those things. For example, to fix up an old commit you jump to it, edit it, and jump back to where you were; to fix a rebase conflict you jump to the conflicting commit, edit it, and jump back to where you were, using the same commands.
– Understanding Jujutsu bookmarks
This is such a good summary, I’m probably going to steal it when I try to explain jj in the future.
It’s been a while since I first talked about rv, a Ruby manager for the future. I’d like give an update on what we’ve done since then, but I’m going to recap some of that earlier post first to give context for the updates. If you still remember what I said back then, you can jump to the new stuff right away. Either way, I’m excited to update you about the work that we’ve been doing, and show exactly how far we’ve gotten.
For the last ten years or so of working on Bundler, I’ve had a wish rattling around: I want a bigger, better dependency manager. It doesn’t just manage your gems, it manages your ruby versions, too. It doesn’t just manage your ruby versions, it installs pre-compiled rubies so you don’t have to wait for ruby to compile from source over and over. And more than all of that, it makes it completely trivial to run any script or tool written in ruby, even if that script or tool needs a different ruby and gems than your application does.
For the entire ten years of daydreaming, I’ve been hoping someone else would build it and I could just use it. Then I discovered that someone did build it… but for Python. It’s called uv. In August 2024, uv version 0.3 shipped, and it had all the features I had wished for, and even more that I hadn’t thought to wish for.
At this point, I’ve been using uv for almost a year and every time I use a project written in Python, the experience is delightful. Not only can you run a command directly out of packages that aren’t even installed, you can run a command that requires a Python version you don’t even have installed. uv takes care of installing the right python, installing the right packages, and running your command, in just a second or two.
Whether you want to run a CLI tool, a webapp, or a random script, uv always ensures the environment is correct as part of running the command. Need Python? Installed. Need a package? Also installed. Never again run pip install on a new package, only to realize later you broke something old. No more setting up dependencies manually, only to discover later that the script stopped working inside cron while you weren’t checking on it.
Last year, my long time consulting job disappeared and I found myself looking for something to replace it. One of my ideas was to start a company inspired by Geomys in the Go language, offering expert advice from open source maintainers, but the idea felt weak to me without a “spotlight” project to show off our expertise. In July of this year, I finally realized that these two ideas could go together extremely well—our company can show our expertise by building this developer tool, and clients paying for our advice to solve their problems can ensure we are able to support and expand the tool.
I talked to some Ruby friends about the idea, and it resonated with them, so we started working on both the company and the open source project. Today, Spinel Cooperative has a website at spinel.coop, and rv has a website at rv.dev. The team has expanded, and now includes David Rodriguez, the former lead developer of RubyGems and Bundler, as well as former Rails core team members Kasper Timm Hanson and Sam Stephenson. Sam has even done some of this work before, as the original creator of rbenv and the ruby-build tool.
Our goal for rv is to be a new kind of developer tool. You don’t need to install rvm and then pick a Ruby version, install it, and then update RubyGems and Bundler, and then bundle install your gems. Instead, you just run the project command you care about, and everything is handled. It’s a version manager, and a dependency manager, and more than both of those things. With that vision in place, we were faced with a very practical question: what can we build that would be useful right away? After some prototyping and a lot of discussion, we landed on precompiled rubies for development work as the most useful place to start, and got to work.
After deciding what our first feature would be, we had to pick a language to use. We landed on Rust to build rv, for two main reasons. The obvious reason is that Rust produces very fast results, and that seems to also be why uv is written in Rust. The less obvious reason is based on years of trying to onboard new contributors to Bundler and RubyGems—it turns out if you are a Ruby developer, you unfortunately don’t (yet) know the subset of Ruby that we have been forced to use to write Bundler and RubyGems.
There are two major things that basically every Ruby program does that you can’t do if you are managing gems. First, you can’t use any gems. If you want to use code that’s inside a gem, you need to copy that code wholesale into Bundler or RubyGems, and then you need to constantly update it anytime that gem has any changes. Second, you can’t use anything with native extensions, ever. JSON gem? Psych gem for YAML? Completely impossible, because Bundler and RubyGems need to be installable even if there is no compiler present.
So with those constraints in mind, and with our goal set to “a tool so fast you normally can’t even tell it’s running”, we settled on Rust, and started building a CLI. I’ve used Rust for smaller personal projects in the past, but I had never created a full CLI tool. I am happy to report that the clap library for creating CLIs in Rust is great, and I recommend it to anyone interested in Rust CLIs.
The next piece that we needed was the actual precompiled Rubies themselves. To install Ruby quickly, we needed to be able to skip over the configure && make && make install dance. There are a couple of big projects out there compiling Ruby in advance, but they are mostly for use on servers. The setup-ruby GitHub action, and the official Ruby docker images are both based on the ruby-build project originally started as part of rbenv. Unfortunately, those aren’t usable for our needs because they aren’t statically compiled and relocatable. Statically compiled (as opposed to dynamically compiled) means that Ruby copies the code from a shared library into its own binary.
Now for small aside (but it’s relevant, I promise). Have you ever had trouble compiling Ruby because of OpenSSL? I’m pretty sure every Ruby developer has. Have you ever had an already-installed Ruby suddenly stop working because of OpenSSL, and you had to install it again? That also seems extremely common, thanks to Homebrew’s aggressive auto-update policy. The good news is, rv fixes both of those problems. By putting OpenSSL inside the Ruby binary, they can never get separated, and those errors can never occur.
There is a tradeoff here—if there is a critical security flaw in OpenSSL, we will need to compile Ruby again to include the critical security update. The first reason we are okay with this tradeoff is that OpenSSL doesn’t have huge security issues very often. The second reason we are okay with this is that your production servers are probably using the official Ruby docker images and not Ruby installed by rv, so it’s even less of a concern.
In the end, the closest existing system we were able find was Homebrew’s portable-ruby project. That’s how Homebrew builds the Ruby install that Homebrew itself runs on. The Homebrew team built some excellent infrastructure for building a statically linked Ruby, including libyaml, openssl, and other required libraries. The big thing Homebrew did not do was build more than one single version of Ruby, or support YJIT. We’ll come back to that in a bit.
The portable part of portable-ruby is about builds being relocatable. Since Homebrew needs to be able to install into /usr/local on x86, but /opt/homebrew on Apple Silicon, and into any user’s home directory for Linuxbrew, they need to be able to take a single precompiled Ruby and put it in any location on disk. That’s another one of the requirements that isn’t met by the setup-ruby or Docker image Rubies—if you move them to another directory, they stop working.
Using Homebrew’s portable-ruby as a base, we were able to start with macOS ARM and Ubuntu x86, add Ubuntu on ARM, and then build every version in the Ruby 3.4.x series. Once we had those ready, then we asked ourselves: how much tooling do we need before this is useful for developers? Just linking to a repo with Ruby binaries in it isn’t really that helpful, because if it’s harder to use than running rbenv install, it’s not really a better or faster experience.
We landed on a small set of useful features for the first version: the latest Ruby minor version, 3.4, built for macOS ARM and Linux x86, with support for .ruby-version files, and automatic Ruby version switching just in zsh.
After a few weeks of work, rv could switch between installed Ruby versions in zsh, but most importantly it could install precompiled Ruby on macOS and Ubuntu in one second flat. Yes, you heard that right. rv ruby install. Wait 1 second. Done. You can run Ruby commands now. With that functionality in place, we released version 0.1.
Immediately after our initial release, we were hit with an extremely nice surprise: someone from the Homebrew core team decided to add rv directly to homebrew-core within a few days of rv 0.1 being released. That makes it much easier to install rv and try it out, and completely removes any need for us to create and maintain our own custom homebrew tap, which is a very nice bonus.
With proof our concept working and users installing v0.1, we immediately started to expand the core functionality. We added support for bash, fish, and nushell. We spent several weeks working through the issues involved in compiling every single point release of Ruby 3.3 and 3.4. Then we spent another two weeks working through all of the issues compiling all of those Rubies with YJIT turned on. Then we spent another two weeks working through the issues of compiling all of those Rubies for macOS on x86, and for Linux on ARM. Once all of those Ruby versions were available, we shipped version 0.2.
Building on our progress with Ruby versions, we added more versions of Ruby: every 3.2.x version, and all of the 4.0 prereleases and final releases. After hearing from asdf and mise users who wanted to re-use their .tool-versions file, we added support for that file as well. Automatic Ruby switching will respect .tool-versions files, and rv ruby pin will update the version written into the .tool-version file if it exists. As a fun easter egg, we also added a precompiled binary of the oldest version of Ruby with published source code, 0.49. All of those features shipped as rv version 0.3.
At that point, we took a break to take stock of the project, our goals, and our plan. rv 0.3 is a pretty good Ruby version manager, and a viable option in the pantheon of Ruby version managers like rvm, rbenv, or chruby. While precompiled Ruby is great, we want superfast installs for not just Ruby but also all gems and bundles. But Bundler is huge! It took three of us a year to build originally, and has had 15 years of additions by dozens of contributors. We can’t build everything we want in a month, or even three. After much brainstorming and discussion, we made a plan to deliver real-world useful tools that would build on each other, so we can work our way up to a complete application dependency management tool.
First, we would need to understand gems themselves, parsing the compact index of gem metadata and then reading gemspecs and .gem files. Then we would need to install gems, not just copy files into the right places but also running the steps to compile native extensions correctly. Once we can install gems into the right places, we need to parse the Gemfile.lock format to install bundles. Then we need to build a resolver, the process that transforms a Gemfile into a Gemfile.lock by taking a list of gems and producing a graph of dependencies that are all compatible with each other. With that plan, we got back to work.
I also want to call out the non-Spinel contributors to rv here. The community that formed around rv and started contributing to it has been amazing. In particular, I want to thank Samuel Giddins for work on gem and gemspec parsing and Ruby shell integration, Adam Chalmers for work on parsing Gemfile.lock and installing gems, and Eric Case for work on Windows and Alpine compatibility. We wouldn’t have made it anywhere close to this far without all of your help.
clean-install command, windows, powershell, and alpineThe first feature from that plan was clean-install, which does the same thing as bundle install --frozen. This is the same thing that you use when you’re running your tests in CI, or that you use when you’re deploying your application to a server. As long as you haven’t made any changes to your Gemfile, we can read the lockfile, install all of your gems, and set up the environment so that your application is able to run. To build this, we implemented a compact index client, gemspec parsing, native gem extension compilation, and gem installation. And it works! Starting with rv 0.4, you can clone a project, install your gems, and run the project.
The next release included a small sidequest to add Windows and PowerShell support, as well as compiling Ruby binaries against musl libc so they will work on Alpine Linux. We use the precompiled binaries for Windows produced by the ruby-installer project, which turns out to be the only existing project that precompiles Ruby. This release also included the next two steps of our incremental plan: first, automatically managing Ruby version and installation. If you rv run irb, you don’t even need to have Ruby installed, rv will make sure that happens if needed.
rvx, and ruby-devThe second part was the next step of our gem management plan, taking a list of gems and resolving dependencies to install. When combined, those two features unlock uv-style “tools”, where a gem CLI can also have an auto-managed Ruby version. Have you ever used gem install to get a CLI tool only to find out later your Ruby version changed and broke the CLI? rv tools completely prevent that problem. With tool support, we could then add gem auto-install to create rvx. Run any gem command, even if it’s not installed! With rv version 0.5, you can go straight from brew install rv to a Rails app from rvx rails new in 10 seconds flat.
At the SF Ruby conference late last year, a random conversation with Kokubun, the ruby-core member and maintainer of YJIT and ZJIT spawned an idea: what about testing against the latest Ruby? The Ruby version managers that compile Ruby onto your own machine handle this by adding a version of Ruby named “dev” that just means “check out the ruby git repo and compile the newest commit”. It was only a few days of effort to get the rv ruby compiler handling ruby from git, but it was a few weeks of experimenting before figuring out how to handle a “version” that keeps the same name but changes every day. It was worth it, though, because now you can install and test against the latest daily Ruby build as easily and as often as you want, without ever waiting for Ruby to compile.
It’s not quite finished yet, but the next step in our incremental plan is to handle the same responsibilities that the bundle install command handles: evaluate the Gemfile, resolve the graph of gem versions, update the Gemfile.lock if needed, and install all of those gems. When I was learning about uv, this part absolutely blew my mind because uv sync is so fast that it runs as part of every command! Coming from Bundler, that was completely incredible. I could not imagine running bundle install before every bundle exec because that would make everything so, so slow. It’s very exciting to work toward that for Ruby.
That’s not all we have planned, either. The rv roadmap includes project setup and task management, making it easy to run scripts or other commands with your Ruby and gems available. Managing gems for scripts means adding a config file as a comment inside the ruby script file, with the Gemfile-like information needed to install gems. rv can then auto-install those gems in order to run the script. It’s not yet clear how long it will take to finish this initial list, even after it’s done we have a ton of additional ideas.
As we wind things up, I want to show off a couple of things that I personally think are the best and coolest uses of rv. this isn’t necessarily the stuff that you’ll do the most often, which is fine, but these examples are super impressive to me, coming from the nightmare of ruby version building.
First up, rvx: once you have rv, you don’t need to think about Ruby, you don’t need to think about gems, you just run the command that you want to run, immediately. rv is fast enough that you can start on a machine with no Ruby installed, run rvx rails new ., and be generating that app in less than 10 seconds. One command to install Ruby, install Rails, install all 60 gems that Rails depends on, and run the command you originally wanted. It’s just an incredibly delightful experience to not need to think about Ruby versions or gem dependencies when you want to run something.
Another thing that has come extremely in handy is the ability to write scripts across Ruby versions, and know those scripts will work whether or not those Ruby versions are installed when the script runs. You don’t need to care about installing Ruby, or even checking for Ruby at all. Just run the command you want to run and rv will take care of all that stuff.
# share scripts using many rubies, all auto-installed
$ rv run --ruby 3.3 bench.rb
$ rv run --ruby 3.4 bench.rb
$ rv run --ruby 4.0 bench.rb
Finally, the rv tool commands (inspired by uv tool) allow you to use CLIs without having to think about Ruby versions, or global gems, or bundled gems, or what application directory you are in. Tools always get the Ruby version and the gems that they need to work, regardless of your currently chosen Ruby version and app and gems. For me, rv tool has unlocked the ability to use Ruby CLI tools again, and I love that power and flexibility.
# CLIs outisde of app Ruby versions and gems
$ rv tool install gist
$ cd ruby-4-app
$ gist
$ cd ../ruby-2-app
$ gist
In the end, we want to live in a future where anyone can run a Ruby command, or tool, or application in a few seconds (or less!). We’re building that future for ourselves, and we welcome everyone else. Visit rv.dev to see the project on GitHub and give it a try! We’d love to have your help building it.
]]>Back in the olden days, when software literally came from BigCo R&D departments, we managed to invent Unix, and the mouse, and GUIs, and Ethernet, and TCP/IP, and a ton of other stuff we all use constantly today. Those research divisions didn’t ship viable consumer products, though. Doug Englebart demoed a mouse-driven GUI in 1968, but you couldn’t buy a home computer with a mouse-driven GUI until 1979, and they didn’t become commercially popular until the Macintosh in 1984.
Even years or decades of research wasn’t enough, and years (or decades!) of development work also needed to be done before the results was ready for people to use. Early literature about creating software, written by Fred Brooks and his peers, seems to contain the internalized view that both R and D are required. That’s not surprising, since R&D departments created most software back then, but we seem to have lost track of that connection.
Even though our jobs are descended from those R&D labs of yore, we somehow lost the industry job of “software researcher”, and only “software developer” remains. Instead, research happens in academia, where an argument and some pseudocode is all you need to publish a paper. In that world, development is effectively non-existent.
(I admit the division isn’t perfectly clear-cut. Sometimes academics will start companies around their research that create a product, or more likely get acquired to add a feature to a product. And sometimes Linus Torvalds will just build a new operating system, without doing any academic research on it, and it will get so popular everyone uses it. The point is that industry and academia have each publicly claimed one half of R&D while disowning the other.)
The broader separation of research and development into academia and industry is really unfortunate, because good software needs both research and development as inputs. If you don’t do any research, you can’t identify which parts will be hard (or impossible) until after it’s too late. You also won’t have a good idea of what parts are important until after you’ve put in most or all of the work to create the parts that don’t matter. If you don’t do development, you won’t ever have something robust enough that other people can use it successfully.
Meanwhile, on the other side, it feels like developers work hard to convince themselves there are no research aspects involved in their jobs. We call anything research-ish by another name, like “design”, “user experience”, “prototyping”, “de-risking”, “a spike”, and a lot of other funny euphemisms that avoid referring to the work as research. It seems like we’re trying to convince ourselves that we don’t do Research any more, because we are just Developers.
This cultural lack of clarity around research in software development spaces really hit hard for me this week, as I read yet another treatise on working with LLM-driven agents for development. The two most popular takes that I have seen are “these tools are a fundamental shift in the nature of software development” and “these tools change nothing about building software at all”. Then the two sides start screaming at each other about how the other side is delusional and time will prove them completely wrong, and I lose interest.
If we instead start from the premise that all software work requires research (where the problem space must be explored) and development (where solutions must be implemented and refined), there’s something hiding in the sometimes messy overlap between those two ideas that I’m not seeing come up in any discussions.
No one can take the output of software research and treat it like it’s the output of software development. Not Bell Labs, not Xerox PARC, not Microsoft middle managers, and not “solo founders managing a team of AI agents” today.
Unfortunately, seeing a prototype and becoming convinced it’s complete is not a new problem. It’s been the bane of software development possibly since the very beginning, when (apocryphally) a manager would review a mockup and conclude the project was now complete and could be shipped to customers immediately. Today, instead of telling that story as a joke, software developers have have somehow turned themselves into the boss from the joke, shouting that it’s time to ship the research prototype because it “looks finished”. How did we do this to ourselves?
It seems like, back when we always had to do all the work ourselves, it was harder for software developers to be confused this way. If a developer knows they skipped every validation and edge case, it’s much easier to realize it’s not finished. If an LLM agent says “here’s a comprehensive implementation”, without mentioning all the validations and edge cases it skipped, many (and possibly most) developers will not notice the parts that are missing.
This phenomenon is bad for a lot of reasons, including one reason you have probably already thought of: we’re going to get a lot more software claiming to be “comprehensive” and “fully implemented” when it’s really a partially finished prototype that’s full of holes.
In a world full of research prototypes being pitched as completed development work, life is about to get worse for everyone who uses software. The docs are even more wildly wrong than they were before, customer support is telling you that your problem is solved by a feature that doesn’t exist, and company leadership is so excited they are planning to fire as many humans as possible so they can have more of it.
I don’t want worse software! The software we already have is mostly terrible. Not only much worse software, but also much more of it, is pretty much my worst case scenario. What I actually want is better software, even if that means less of it.
Unfortunately, instead of making better software, software developers have decided to become the butt of their own joke, shipping software that doesn’t work, with a footnote that says they know it doesn’t work but they are still shipping it. I don’t see any way to stop it, but I hate it anyway.
]]>In all three cases, Ruby Central found no evidence of compromised end user data, accounts, gems, or infrastructure availability. I hope this can conclusively put to rest the idea that I have any remaining access to the RubyGems.org production systems, or that I caused any harm to the RubyGems.org service at any time.
I also appreciate that Ruby Central is taking its share of responsibility, recognizing that its lack of communication with the former maintainers (including me) created confusion and frustration that contributed, in part, to how we ended up where we are today.
Ruby Central board members Freedom, Brandon, and Ran state that their intent is now to work towards an amicable resolution. I salute their new commitment, and would like to do my part to help the RubyGems community move past these unfortunate events, with a resolution that puts the dispute fully behind us, and allows all of us to move forward.
For my part, despite my claims against Ruby Central, and the threats they have directed against me, I am willing to completely settle all of my disputes with them, and pledge to take no legal action against Ruby Central regarding any of their actions prior to today.
In exchange, I am requesting two things.
First, I am asking Ruby Central to drop their legal threats, including releasing their claims against me and reimbursing my legal costs. Those costs arise from Ruby Central’s actions, including litigation threats, other escalations, and most recently contacting law enforcement. In addition to forcing me to retain counsel, these actions caused considerable stress and disruption. I am willing to provide invoices to ensure the reimbursement precisely matches only my actual costs.
Second, I am asking Ruby Central lay our disagreement to rest with a public statement acknowledging that I did no harm to the RubyGems.org service.
If Ruby Central fully drops their legal claims, and states I did not harm the RubyGems.org service, I would consider our disagreement amicably settled.
]]>Hello, and welcome to How To Install A Gem. My name is André Arko, and I go by @indirect on all the internet services. You might know me from being 1/3 of the team that shipped Bundler 1.0, or perhaps the 10+ years I spent trying to keep RubyGems.org up and running for everyone to use.
More recently, I’ve been working on new projects: rv, a CLI to install Ruby versions and gems at unprecedented speeds, and gem.coop, a community gem server designed from the ground up so Bundler and rv can install gems faster and more securely than ever before.
So, with that introduction out of the way, let’s get started: do you know how to install a gem? Okay, that’s great! You can come up and give this talk instead of me. I’ll just sit over here while you write the rest of this post.
Slightly more seriously, do you know how gem install converts the name that you give it into a URL to download a .gem file? It’s called the “compact index”, and we’ll see how it works very soon.
Next, who in the audience knows how to unpack a .gem file? Do you know what format .gem files use, and what’s inside them? We’ll look at gem structure and gemspec files as well.
Then, do you know where to put the files from inside the gem? Where do all of these files and directories get put on disk so we can use them later? Does anyone know off the top of their head?
Once those files have been unpacked into the correct places, the last thing we need to know is how to require them. How do these unpacked files on disk get found by Ruby, so you can require "rails" and have that actually work?
This exercise was mostly to show that using gems every day actually skips over most of the way they work underneath. So let’s look at what a gem is, and examine how they work. By the end of this talk, you’ll know what’s inside a gem, how RubyGems figures out what to download, and where and how that download gets installed so you can use it.
And if you already everything we just talked about, please feel free to go straight to rv.dev and start sending us pull requests!
First, we’re going to look at how the name of a gem becomes a URL for a .gem file. Let’s use rails as our example. Historically, there have been at least five or six different ways to look up information about a gem based on its name, but today there is one canonical way: the compact index. It’s so simple that you can do it yourself using curl. Just run curl https://gem.coop/info/rails, and you’ll be able to read the exact output that every tool uses to look up the versions of a gem that exist. Each line in the file describes one version of the gem, so let’s look at one line.
❯ curl -s https://gem.coop/info/rails | tail -n 1
8.1.3 actioncable:= 8.1.3,actionmailbox:= 8.1.3,actionmailer:= 8.1.3,actionpack:= 8.1.3,actiontext:= 8.1.3,actionview:= 8.1.3,activejob:= 8.1.3,activemodel:= 8.1.3,activerecord:= 8.1.3,activestorage:= 8.1.3,activesupport:= 8.1.3,bundler:>= 1.15.0,railties:= 8.1.3|checksum:6d017ba5348c98fc909753a8169b21d44de14d2a0b92d140d1a966834c3c9cd3,ruby:>= 3.2.0,rubygems:>= 1.8.11
We can break down that line with split(" "), and tackle each part one at a time.
First, 8.1.3. That’s the version of rails that this line is about. So we now know for sure that rails 8.1.3 exists.
Next, a list of dependencies. The rails gem (version 8.1.3) declares dependencies on a bunch of other gems: actioncable, actionmailbox, actionmailer, actionpack, actiontext, actionview, activejob, activemodel, activerecord, activestorage, activesupport, bundler, and railties. Each dependency has a version requirement attached, and for almost every gem it is exactly version 8.1.3, and only version 8.1.3. For bundler, Rails is a little bit more flexible, and allows any version 1.15.0 and up.
The final section contains a checksum, a ruby requirement, and a rubygems requirement. The checksum is a sha256 hash of the .gem file that contains the gem, so after we download the gem we can check to make sure we have the right file by comparing that checksum.
For this version of Rails, the required Ruby version is 3.2.0 or greater, and the required RubyGems version is 1.8.11 or greater. It’s up to the client to do something with that information, but hopefully you’ll see an error if you are using Ruby or RubyGems that’s too old.
Great! So now we know the important information: Rails version 8.1.3 is real, and strong, and is our friend. We can download it, and check the checksum against the checksum we were given in the info file line. Let’s do that now:
❯ curl -sO https://gem.coop/gems/rails-8.1.3.gem
❯ sha256sum rails-8.1.3.gem
6d017ba5348c98fc909753a8169b21d44de14d2a0b92d140d1a966834c3c9cd3 rails-8.1.3.gem
Notice that the checksum produced by sha256sum exactly matches the checksum we previously saw in our line from the info file: 6d017ba5348c98fc909753a8169b21d44de14d2a0b92d140d1a966834c3c9cd3. That lets us know that we got the right file, and there were no network or disk errors.
Now that we have the gem, we can investigate: what exactly is inside a gem? At this point, we’re going to pivot from the rails gem to the railties gem. There’s a good reason for that, and the reason is… the rails gem doesn’t actually have any files in it. So it’s a bad example. In order to show off what a gem looks like when it has files in it, we’ll use railties-8.1.3.gem instead.
So, we have our .gem file downloaded with curl. What do we do now? The first piece of secret knowledge that we need: gems are tarballs. That means we can open them up with regular old tar. Let’s try it.
❯ tar xfvz railties-8.1.3.gem
x metadata.gz
x data.tar.gz
x checksums.yaml.gz
So what’s inside the .gem tarball is… another tarball. And also two gzipped files. Let’s look at the files first.
❯ gzcat checksums.yaml.gz
---
SHA256:
metadata.gz: 8326ab6cc8e325055394ebd19c41d895e9ebd48e4752ec90d5c4675935516e6e
data.tar.gz: 4152d8f55ae639d899f1cb6c54e1e93bb158bb76026b253482c5ae0343ac5aec
SHA512:
metadata.gz: f6aa3390b6b1699255f1dbc6c6f24c6d9c18d3bfa48f10b6d720595384b4d1bb26f92232adb7011d3b1e7e977ca775cd253a12a135fe83eaa21e10dd0f14f779
data.tar.gz: a001cebc5b97f627336a3e8d394c4ecac4a5d2b9e62c82de3b484470a58deac7c8ff0a8e8b497843386b1639c9cbfdfabee2cc7b2d483469e00a0b01da6bd41d
As you might expect from its name, the checksums.yaml.gz file is a gzipped YAML file, containing checksums for the other two files. It’s maybe a bit silly to have multiple layers of checksumming here, but it does confirm that the outer layer of tarball and zip was removed without any errors.
Okay, so what’s inside metadata.gz? The answer is… Ruby, sort of. It’s a YAML-serialized instance of the Gem::Specification class. We can see exactly what was put into this object at the time the gem was built.
After snipping out the YAML that lists the dependencies (which we already looked at, because they are included in the info file), what’s left is some relatively simple information about the gem. Author, author’s email, description, homepage, license, various URLs.
❯ gzcat metadata.gz
--- !ruby/object:Gem::Specification
name: railties
version: !ruby/object:Gem::Version
version: 8.1.3
platform: ruby
bindir: exe
executables:
- rails
require_paths:
- lib
authors:
- David Heinemeier Hansson
summary: Tools for creating, working with, and running Rails applications.
description: 'Rails internals: application bootup, plugins, generators, and rake tasks.'
email: david@loudthinking.com
homepage: https://rubyonrails.org
licenses:
- MIT
metadata:
bug_tracker_uri: https://github.com/rails/rails/issues
changelog_uri: https://github.com/rails/rails/blob/v8.1.3/railties/CHANGELOG.md
documentation_uri: https://api.rubyonrails.org/v8.1.3/
mailing_list_uri: https://discuss.rubyonrails.org/c/rubyonrails-talk
source_code_uri: https://github.com/rails/rails/tree/v8.1.3/railties
rubygems_mfa_required: 'true'
rubygems_version: 4.0.6
specification_version: 4
files:
- CHANGELOG.md
- MIT-LICENSE
- RDOC_MAIN.md
- README.rdoc
- exe/rails
- lib/minitest/rails_plugin.rb
- lib/rails.rb
[...]
For the purposes of installing and using the gem, we care about exactly six pieces of information: name, version, platform, bindir, executables, and require_paths.
We’re going to combine those items with the files in the remaining data.tar.gz file to get our unpacked and installed gem.
Now that we know what’s in the gem specification, let’s look at what’s inside the data tarball. It matches up very closely with the long list of entries in the files array in the gemspec.
❯ mkdir railties-8.1.3
❯ tar xfvz data.tar.gz -C railties-8.1.3
x CHANGELOG.md
x MIT-LICENSE
x RDOC_MAIN.md
x README.rdoc
x exe/rails
x lib/minitest/rails_plugin.rb
x lib/rails.rb
[...]
So now we have a bunch of files. Where are we going to put these files? Enter: the magic of RubyGems. The scheme that RubyGems has come up with is largely shaped by the constraints of how Ruby finds files to require, which we’re going to look at soon. For now, it is enough for us to know that RubyGems keeps track of a list of directories, a lot like the way $PATH works for your shell to find commands to run. To find the current directory, you can run ruby -e 'puts Gem.dir. Here’s what that looks like:
❯ ruby -e 'puts Gem.dir'
/Users/andre/.gem/ruby/4.0.0
❯ ls ~/.gem/ruby/4.0.0 | xargs -L1 echo
bin
build_info
cache
doc
extensions
gems
plugins
specifications
From this list, we can see that RubyGems organizes its own files into a few directories. To install a gem, we’re going to need to put the files we have into each of those directories, with specific paths and filenames.
Just to recap, the files we need to place somewhere are:
So let’s move the files into the directories we see RubyGems offers.
First, cache the .gem file so RubyGems doesn’t need to download it again later:
mv railties-8.1.3.gem ~/.gem/ruby/4.0.0/cache/
Then, add the gem specification so that RubyGems will be able to find it. There’s a small twist here, which is that the specifications directory doesn’t contain YAML files, it contains Ruby files. So we also need to convert the YAML file back into a Ruby object, and then write out the Ruby code to create that object into a file that RubyGems can load later.
❯ gunzip metadata.gz
❯ ruby -ryaml -e 'puts YAML.unsafe_load_file("metadata").to_ruby' > ~/.gem/ruby/4.0.0/specifications/railties-8.1.3.specification
Next, we need to put the files that make up the contents of the gem into the gems/ directory.
❯ mv railties-8.1.3 ~/.gem/ruby/4.0.0/gems/
❯ ls ~/.gem/ruby/4.0.0/gems/railties-8.1.3
CHANGELOG.md
exe
lib
MIT-LICENSE
RDOC_MAIN.md
README.rdoc
One more thing we need to do: set up the executables provided by the gem.
You can check out the files that RubyGems generates by looking in ~/.gem/ruby/4.0.0/bin, but for our purposes we just need to tell RubyGems what gem and executable it needs to run, so we can do that:
❯ cat <<EOF > ~/.gem/ruby/4.0.0/bin/rails
#!/usr/bin/env ruby
require "rubygems"
Gem.activate_and_load_bin_path("railties", "rails")
EOF
❯ chmod +x ~/.gem/ruby/4.0.0/bin/rails
And with that, we’ve installed the gem! You can run the rails file that we just created to prove it:
❯ ~/.gem/ruby/4.0.0/bin/rails
Usage:
rails COMMAND [options]
You must specify a command:
new Create a new Rails application. "rails new my_app" creates a
new application called MyApp in "./my_app"
As we wrap up here, there are three aspects of gems that we haven’t touched on at all: docs, extensions, and plugins. We don’t have time to talk about them today in this meetup talk slot. Hopefully a future (longer) version of this talk will have space to include all of those things, because they are all super interesting, I promise.
In the meantime, I will have to direct you to the docs for RDoc to learn more about docs, to the source code of rv or RubyGems itself if you want to learn more about gem extensions and plugins.
require find a gem?There’s one last thing to figure out before we wrap up: how does require find a gem for us to be able to use it? To explain that, we’ll have to drop down to some basic Ruby, and then look at the ways that RubyGems monkeypatches Ruby’s basic require to make it possible to have gems with versions.
The first thing to know about require is that it works exactly like $PATH does in your shell. There’s a global Ruby variable named $LOAD_PATH, and it’s an array of paths on disk. When you try to require something, Ruby goes and looks inside each of those paths to see if the thing you asked for is there.
You can test this out for yourself in just a few seconds! Let’s try it.
❯ mkdir lib
❯ echo 'puts "this is some ruby"' > lib/my-file.rb
❯ ruby -Ilib -e 'puts $LOAD_PATH.first; require "my-file"'
/Users/andre/lib
this is some ruby
The Ruby CLI flag -I lets you add directories to the $LOAD_PATH variable, and then the require function looks inside that directory to find a file with the name that you gave to require. No magic, just a list to check against for files on disk.
Now that you understand how the $LOAD_PATH variable makes require work, how does RubyGems work? You can’t just put ten different versions of rake into the $LOAD_PATH and expect require to still work. RubyGems handles multiple versions of the same rake.rb file by monkeypatching require.
Let’s look at what happens when we require "rails", which is a file located inside the railties gem that we just installed. RubyGems starts by looking at all of the gem specifications, including the one we saved earlier. In each specification, it combines the name and version with the values in require_paths to come up with a path on disk.
So for our just-installed railties gem, that would mean a path of: ~/.gem/ruby/4.0.0/gems/railties-8.1.3/lib. RubyGems knows that directory contains a file named rails.rb, so it is a candidate to be “activated”, which is what RubyGems calls it when a gem is added to your $LOAD_PATH.
As long as internal bookkeeping shows that no other versions of railties have already been added to the $LOAD_PATH, we’re good! RubyGems adds this specific directory to the $LOAD_PATH, and delegates to the original implementation of require. Require finds the file at ~/.gem/ruby/4.0.0/gems/railties-8.1.3/lib/rails.rb, reads it, and evaluates it.
With that, we’ve done it! We have found, downloaded, unpacked, and installed a gem so that Ruby is able to run a command and load ruby files, without ever touching the gem install command.
If you’re interested in contributing to an open source project that works a lot with gems, we would love to work with you on rv, where we are working to create the fastest Ruby and gem manager in the world.
And of course, if your company could use faster, easier, or more secure gems for developers, for CI, and for production deployments, we can help. We’d love to talk to you and you can find our contact information at spinel.coop.
]]>Last year, Ruby Central flipped that successful formula on its head. They now claim ownership of both Bundler and RubyGems, but refuse to provide governance. Ruby Central now claims sole control over all code and decisions, despite paying for only a few percent of the work required to create and sustain the projects across 22 years. Instead of providing stable and predictable processes, Ruby Central suddenly hijacked the Bundler and RubyGems codebases away from the existing maintainers, shut out the community, and started issuing the threats to sue.
When confronted by the former maintainers after the hijacking, Marty Haught of Ruby Central stated (in a recorded video call) on September 17 that “yeah, we shouldn’t have changed that”. On September 18, Marty went on to write:
In the past, we’ve made the mistake of conflating ownership of the code with ownership of the infra, and vice versa, and we’d like to straighten this out so that we aren’t put in a legal bind that requires us to take control of the entire codebase when, we all agree, that is not proper or correct given the existing model.
In the words of Ruby Central itself, “we all agree, [taking control of the entire codebase] is not proper or correct.” Since the beginning of this conflict, Ruby Central has privately admitted it was wrong to hijack the GitHub organization and steal the repos, but has refused to acknowledge this in public. Unfortunately, despite privately admitting their actions were wrong, Ruby Central has publicly continued to dig their hole deeper. Instead of owning up to their mistake, they secretly negotiated a deal with Matz for ruby-core to take over the stolen RubyGems and Bundler repository, further violating the project governance policies.
If this situation were just about me personally, I could believe it sprang from from individual disagreements. Ruby Central claims they had good reasons to unilaterally kick me out of the project, even though I don’t think their claims hold water. With that said, regardless of what you think about me personally, the other five long-term maintainers have never gotten any explanation of why they were suddenly kicked out or bypassed entirely, all in violation of existing project governance.
In her only public interview about the situation, Ruby Central Executive Director Shan Cureton defended stealing Bundler from its team of fifteen years by saying the removed team “didn’t need to have the story, and it wasn’t their story to have”. Ruby Central has made their position clear: if they steal your project, you are not entitled to know their reasons, and neither is anyone else. There is nothing “community-oriented” about stealing the most-used gem in Ruby and refusing to share your reasons with the community.
Despite Ruby Central’s unacceptable treatment of both projects and maintainers, the former RubyGems and Bundler team said we want to move Ruby forward. We offered Ruby Central a path to move past their illegitimate GitHub takeover, past their vicious personal attacks, and past their threats to sue us.
It has been four months since we made that offer, and Ruby Central has not accepted.
While declining to accept our offer, Ruby Central has nonetheless found the time to propose new governance documents for RubyGems. In those documents, they explicitly require existing maintainers approve adding or removing team members. That rule was already present in the previous governance, and is the exact rule that Ruby Central violated to execute their takeover. When asked why they violated the previous governance, and why the new governance would be any more trustworthy, Ruby Central refused to respond substantively, and then the question itself was hidden by marking it “off topic”.
Instead of working to resolve the situation, Ruby Central has spent 4 months rejecting requests for an explanation, while repeatedly threatening to sue me personally. After Ruby Central suddenly took over the Bundler repo, I sent them a standard trademark notice. They replied with a threat to sue me. When I later informed Ruby Central I had learned they violated state employment law, they simply replied with the same threat to sue me again. They are threatening to sue me for “hacking” them, despite their own analysis publicly concluding “no evidence that user data or production operations were harmed”.
Without seeking common ground, or even looking for some sort of resolution we can just live with and move on from, Ruby Central has offered all of us — nothing. Ruby Central has made no offer in reply to outreach from the other five maintainers. To me, after four grueling months of private “negotiation”, their entire offer is nothing more than to refrain from suing. But only if I agree to everything that they want.
They say I must agree that I have no claim on the name Bundler, despite helping create it and leading the Bundler team for the last 15 years. They say I must agree I was paid legally and fairly, when California law clearly states I was not. They say I must agree that Ruby Central can take over open source projects they host, any time they feel like it, with no explanation, and no consequences.
I don’t agree.
Letting this situation stay unaddressed sets a dangerous precedent for all open source projects written in Ruby. Ruby Central has resolved nothing. Don’t let their delaying tactics convince you otherwise. The Ruby community cannot trust Ruby Central with control over our gems until there is accountability for destroying the very governance they were supposed to be providing.
Until accountability arrives, take action. Tell Ruby Central they owe everyone an explanation for violating the project governance around six long-term maintainers, not just me. Don’t sponsor, attend, or speak at RubyConf. Contribute to projects that aren’t controlled by Ruby Central.
The exiled maintainers are working on new projects, with a focus on clear governance, long-term financial sustainability, and community input: Join the gem.coop beta, and stop using RubyGems.org. Use jwl instead of RubyGems. Use rv or Ruby Butler instead of Bundler.
A better world is possible! Ruby Central might want to keep Ruby in the past, but we can work together to build Ruby a future.
]]>As part of our quest to build a fast Ruby project tool, we’ve been hard at work on the next step of project management: installing gems. As we’ve learned over the last 15 years of working on Bundler and RubyGems, package managers are really complicated! It’s too much to try to copy all of rbenv, and ruby-build, and RubyGems, and Bundler, all at the same time.
Since we can’t ship everything at once, we spent some time discussing the first project management feature we should add after Ruby versions. Inspired by npm and orogene, we decided to build clean-install. Today, we’re releasing the rv clean-install command as part of rv version 0.4.
So, what is a clean install? In this case, clean means “from a clean slate”. You can use rv ci to install the packages your project needs after a fresh checkout, or before running your tests in CI. It’s useful by itself, and it’s also concrete step towards managing a project and its dependencies.
Even better, it lays a lot of the groundwork for future gem management functionality, including downloading, caching, and unpacking gems, compiling native gem extensions, and providing libraries that can be loaded by Bundler at runtime.
While we don’t (yet!) handle adding, removing, or updating gem versions, we’re extremely proud of the progress that we’ve made, and we’re looking forward to improving rv based on your feedback.
Try running brew install rv; rv clean-install today, and see how it goes. Is it fast? Slow? Are there errors? What do you want to see next? Let us know what you think.
While working on rv, there’s a specific question that has come up over and over again, in many different forms. In the simplest possible form, it boils down to:
What is the difference between
rv execandrv run? Why have both?
We haven’t finished implementing either rv exec or rv run yet, but every time one or the other comes up in a conversation, everything instantly becomes more confusing.
This post will summarize the history of exec and run in Bundler, npm, Cargo, and uv. Once we have the history laid out, we can take a look at what we plan to do in rv, and you can give us your feedback.
execBundler manages project-specific packages, but not generally available “global” commands. Project-specific packages installed with Bundler can include their own commands.
While working on Bundler 1.0, we needed a standard way to do something new: run commands completely scoped inside a project, rather than scoped to the entire Ruby installation on the current machine. We tried both a wrapper command (bundle exec COMMAND) and generating dedicated scripts in the project’s bin/ directory. With binstubs, you could run bin/rake to get the project rake, and rake to get the global rake.
I personally preferred the binstub approach, but it was bundle exec that ultimately became the popular way to use commands inside your project. My theory is that it won because you can use it to run any command, including ruby, or bash, or anything else you want.
execSomewhat confusingly (inspired by the npm exec command explained below) there is a separate gem exec command that is not related to Bundler and instead installs and runs a command from a package. RubyGems only manages global packages and commands, so gem exec is more of a convenience to make it easier to globally install and run a package with just one command.
run and execnpm manages both project-specific and global packages, and can install any package so its commands are available either only within a project or globally across every project that uses the same version of Node.
The project-focused design of npm expects commands from project packages to be run by first adding the command to package.json in the script section, and the run via npm run SCRIPT. This is even more inconvenient than Bundler’s binstubs, and so I think there was pent-up demand to be able to “just run a command directly”. That was eventually provided by npm exec and its alias npx.
The npx COMMAND setup makes it very easy to run any command, whether the package is in the local project or not, whether a script is set up or not, and even whether the package is installed at all or not. Simply running the command is enough to install the needed package and run its command.
It’s especially helpful to have npx available when you need to create a new project by running an npm package, since it’s a huge pain to create a project and install a package and set up a script just so you can run the package to overwrite your project. The most popular example of this I am aware of is npx create-react-app, but it’s a popular idiom for many packages that contain commands.
run and installCargo is simalarly a package manager, but unlike Ruby and Node, project-level packages do not include commands, and package commands are installed globally. Library packages are added to a project with cargo add, while command packages are installed globally with cargo install. Once a package is installed globally, it can simply be available on your $PATH, and Cargo no longer has to be involved in running it.
The cargo run command is extremely limited in scope, and only allows you to build and run a binary created by your own project – it does not work to run commands from packages, either project-local or global.
exec and runIn uv, the exec command seems to be most strongly inspired by npm exec, including having its own short alias of uvx. The uv exec command is exclusively for running commands directly from packages, automatically installing them if necessary. To give an example, that means you can use uv exec github-backup to install and run the github-backup command from the Python package named github-backup, whether or not that packge is included in your current project.
Conversely, the uv run command is closer to bundle exec: it installs and configures Python, installs project packages if inside a project, and then runs a command from $PATH or runs a file. That means uv run can be used for both uv run bash to get a shell with only your project’s Python and packages, and can also be used as uv run myscript.py to run a script file directly.
bundle exec runs:
bundle exec rails)bundle exec bash)bundle exec ./myscript.rb)npm run runs:
npm run my-project-script), which can call:
generate_pdf.js)bash)./myscript.js)npm exec installs and runs:
npx create-react app)cargo run builds and runs:
uv run installs python and any project packages, then runs:
uv run datasette)uv run python)uv run ./myscript.py)uv run my-project-script), which can call:
github-backup)bash)./myscript.py)uv exec installs python and the named package, then runs:
uv exec github-backup)rvWith all of that background now set up, what should rv exec do? What should rv run do?
To be the most like Bundler, we should use rv exec to run commands for a project. To be the most like npm and uv, we should use rv exec to install and run a single package with a command.
Today, we’re leaning towards an option that includes all of the useful functionality from every command above, and aligns Ruby tooling with JS tooling and Python tooling:
rv run installs ruby and any project packages, then runs:
rv run rspec)rv run bash)rv run ./myscript.rb)rv run my-project-script), which can call:
rspec)bash)./myscript.rb)rv exec installs ruby and the named package, then runs:
rv exec rails)If we try to combine those two commands into one command, we quickly run into the ambiguity that has been so frustrating to handle in Bundler for all of these years: if you rv run rake, do you want the global rake package? Or do you want the project-local rake package? How can we know which you want?
In my opinion, uv solves this relatively elegantly by having uvx always run a package globally, and uvr always run a package locally inside the current project, if one exists.
What do you think? Let us know in the GitHub discussion about this post.
]]>Welcome! This is meant to serve as an introduction to deployment and operations for newer developers, but it’s also a checklist that I refer back to even after 20 years of deploying Rails apps to production. What needs to be covered when going to production the first time? What needs to be covered when going to production for the 1000th time?
Before we get into those details, let me introduce myself. I’m André Arko, better known as @indirect on the internet. My biggest Ruby claim to fame is leading the Bundler and RubyGems OSS team for the last 15 years or so. Ruby Central recently kicked out the existing team, so the former RubyGems team has set up a new community-focused gem server at https://gem.coop. I hope you’ll check it out.
But I’m here to talk about deploying and operating Rails applications, so let’s get going. I built my first Rails application in 2004, and trying to get that application off my laptop so other people could use it is what started me down the path to madness and devops. It’s been a long journey, and I have learned many things from over 20 years of watching Rails apps break in production.
Let’s set the scene: an excited Ruby developer follows a Rails tutorial, creating a blog, a todo app, or some other cool idea. They walk through the code, the tests, the features. They finish the tutorial, and have a full Rails application, something cool that they want to show off to other people! That’s when they realize… this is only on their laptop, and no one else can see or use it.
The most useful tutorials will mention hosting options at this point, maybe Heroku, Fly.io, Render, Railway, or DigitalOcean. If they’re unhelpful tutorials, they might mention AWS, GCP, or Azure. But no matter what service they suggest, coding tutorials need to stay focused, and refer developers out to a hosting service when they want to deploy.
This is a problem, because the tutorials about how to deploy on those hosting sites all say things like “of course this introduction does not include how to secure your secrets in production”. In fact, hosting tutorials usually just wave their hands and skip over most aspects of deploying and operating a true production application. I’m not sure how they expect a new dev to learn these skills, exactly, but that’s what I’m going to try to cover in this talk today.
So our hypothetical Rails developer has followed a hosting tutorial, and has a shiny new application and database deployed to Heroku, or Fly.io, or Render, or whatever. Now is when they actually start to run up against the real problems of running in production: are the secrets secure? is the database backed up? what happens if there’s an exception? how do you debug something that only happens on the server?
Let’s break down each of the new kinds of preparation needed by category, and walk through what you need to do, and why you need to do it. Ultimately, everything that we are going to talk about today is about confidence. Everything happening in deployment and operations, in devops, in SRE, is all being done to increase confidence in the application—your own, your coworkers, or your customers.
The areas we’re going to look at today are Errors, Data, Speed, Security, and what usually gets called Lead Time. Lead Time is the amount of time it takes for a change to go from a commit to live in production. Investing in a shorter Lead Time can return absolutely outsized benefits in every other area, because it means you can try a change, learn from it, and make another change in reaction, faster and faster. We’ll talk a bit more about it at the end.
To start with, let’s focus on Errors. Conceptually, an error is any time that your user isn’t able to use your site. More specifically, an error could mean your Ruby code threw an exception, it could mean some configuration is preventing your app from working correctly, or it could mean that your servers have completely blown up and there is no app available for your users to talk to. With that in mind… how will you know? That’s the first and most important rule of running applications in production. You need to know in advance how you’re going to find out if something is broken.
It’s not popular deployment advice, but the most important way to build confidence and in your application is to test it. Test it manually, test it automatically, have other people try it and report back. Each of those things will save you more time debugging than you can even imagine right now.
Next, one of the most popular ways to increase confidence before a deploy is a second environment where you can deploy your code to test it before it is live on the main site. The test area is usually called “staging”, and the main area is usually called “production”. Rails has built-in support for both of those, as well as “development”, which runs by default on your local development machine.
Use the staging environment as a place where you can put code that you aren’t sure about, and try the new version there. After you have confidence (there it is again) in your new changes, you can “promote” them to production. Some platforms even let you bump staging to production without having to wait for a full new production deploy.
After you’re releasing code with manual and automatic tests to staging and then production, the next most common mitigation strategies are exception reporting and uptime monitoring. Exception reporting does exactly what it sounds like, and sends a report to you when there is an exception in your application.
Personally, I tend to use honeybadger.io to set up exception tracking and uptime monitoring. It’s free for a single user, which is great for my personal project, and I am apple to connect it to Slack so I get notifications if there are Ruby or Javascript errors, or if the site stops being reachable from the internet. Other popular options for tracking exceptions include Sentry, Airbrake, Bugsnag, and more that you can easily find with a search.
For anything that’s less significant than an exception, or to help you investigate when an exception does occur, you’ll also want to think about what usually gets called “instrumentation” or “observability”. The most basic level here is just seeing the logs from your application, and most hosting will provide a way for you to do that.
The more advanced levels of observability include setting up additional tracking in your application, both inside the Rails framework and inside your own code. This tracking can take the form of metrics, which are numbers counting when and how many times some particular thing has happened. Monitoring that focuses primarily on metrics includes using the Prometheus open source tool, or DataDog, AppSignal, NewRelic, and others like them.
Monitoring can also take the form of traces, where your application keeps track of how long each part of a response takes, letting you see each controller, parameter, database query, http request, and anything else that happened. If you’ve ever heard of OpenTelemetry, this is what that is about. Honeycomb.io is the pioneer of this style of monitoring, but others like Sentry and DataDog have also added the ability to collect and review traces.
I don’t always find Honeycomb’s “only events and traces” style easier to use than simply reading logs, but it regularly helps me solve debugging mysteries that I would not have been able to figure out from solely reading logs, so I’m very glad to have it as an option.
Lastly on the topic of errors in production, the open-ended question to ask yourself is “how will people tell me about problems?”. Do you have a contact form? A support email? A social media profile? Make sure there’s some way to hear from your users, because there will always be something that doesn’t set off your monitoring but still needs to be fixed… if you can hear about it.
Next up is Data. Data includes not just the stuff that users have uploaded and put directly into your database, it also includes uploaded files, and anything else that you might want while recovering from a catastrophic server failure. Server failures range from the very mundane server part died to the very surprising truck rammed into the data center’s power transformer, but they all have the same end state: your server is gone.
Now that your server is gone, you need to set up something again. This is the touchiest part of any production service. Do you have a copy of the latest code? A recent database backup? Uploaded files saved somewhere you can still get to them?
Start with the code. Make sure that you deploy to production by pushing to a code host and deploying from there. Most often that means GitHub and a deploy from GitHub Actions, but the important part is that any code that goes live needs to be easy to find even if your laptop vanishes.
Next, handle the database. Use a system that automatically takes daily snapshots of your database, or build something yourself that creates daily copies. For my side projects, I have set up a daily GitHub Action that connects to my database, pulls out a copy, and uploads it as an artifact. Actions artifacts have no size limit, and just time out after 90 days, which is perfect for daily backups.
Test your backups. More than one startup has completely failed and shut down when they discovered that their backups weren’t actually running, or the results were corrupted, only after it was too late. Have more than one backup, preferably one per day, and test your backups system regularly. That’s the second, and most important, rule of running applications in production.
Once you have your database(s) taken care of, it’s time to look at your user uploaded or created files. Using a file service like S3, B2, R2, Google Cloud Storage, or Tigris can be a huge advantage here. Those services all provide a basic promise that your files will be copied to at least 3 places at all times. While it’s possible to run your own copy of Minio and treat it like S3, if the filesystem backing your Minio server crashes, those files are gone. I don’t recommend doing that unless you’re sure those files don’t really matter.
Lastly for data, you now need to think about how you are going to deal with all of the existing production data, now constantly growing, that you can’t just erase. In local development, if your schema gets into a weird state, it’s easy to just create a new database and import the schema again. Now that you have a live, production database, you can’t do that.
Adding, removing, and renaming database columns are all now potentially actions that could break your application. To avoid full site downtime, you need to deploy code that can handle both the old schema and the new schema, then run the schema migration, then remove the handler code and deploy again. I recommend adding the strong_migrations gem as soon as you have a live production site, to add some guardrails that will make it harder to accidentally break either the site or your users’ data.
Now let’s talk about speed. Speed from a Rails app? It’s possible! In my experience, the biggest reasons that Rails apps get slow are external API calls, responses with no pagination, and accidental N+1 database queries. Rails may not be the most performant framework in the world, but it can be perfectly usable as long as you avoid those traps.
Why does the speed of your application matter? As mentioned at the start, it comes down to confidence. If users can see what is happening quickly, they trust your app to be working correctly. If your application matter takes so long that users lose interest or get distracted, that confidence is gone. Whatever did happen with that thing… hmm, I dunno.
Use the monitoring and observability tools we talked about before to keep an eye on how long your application is taking to do things. Don’t use the average, because averages don’t reflect any actual user experience. Instead, track a percentile that reflects how many users you can tolerate having a bad experience.
If you have 10 users per day, maybe the 90th percentile performance is what to watch because only 1 person will have a worse experience. If you have 10 million users per day, you might want to track the 99.99th percentile, because that’s still 1000 people every day having a worse experience than that number.
When you find something that’s slow, your main tools to fight against it are monitoring and profiling. Monitoring can tell you which users experienced the slowness, and what they were trying to do. It might even be able to tell you which SQL queries or HTTP calls made things so slow. Meanwhile, profiling can tell you what code is being run inside a given action, and help you optimize it. The rack-prof gem is the most well-known profiler, but there are multiple options available.
Now that you know how and why to keep your app fast, let’s talk about security. There are two resources your production application has that you now need to defend: user data, and servers on the internet. One class of attacks will try to break in to your application to steal user data, like emails, phone numbers, whatever you have stored. The other type of attack is about hijacking your server to do something for the attacker, like send spam or show ads or mine cryptocurrency.
The best defense for user data is to not store it at all. If you don’t absolutely need it, don’t collect it, and then no one can steal it. If you need to collect user information, make sure you are only collecting what you need. If your users are supplying personal information, especially sensitive financial or identity information, make sure the data is encrypted inside the database so a simple database leak won’t reveal it. It’s not hard to encrypt a single model column anymore, so be sure to do it!
The best defense against attackers who want to hijack your servers is to update your libraries. Use a tool like Dependabot or Renovate to apply security fixes, so your application isn’t vulnerable to known hacks. Set up a monitoring alert on your CPU and disk usage. Set up a billing alert for if your usage goes above your usual amount, so you can investigate.
Ultimately, it’s always worth it to have a security policy, even if it’s very simple. Provide contact information so problems can be brought to your attention. You don’t need to have a security team and a HackerOne program, but you do need to have a basic awareness of what could go wrong and how you can approach handling it. Knowing you have backups that can’t be deleted by someone hacking into your server is a huge advantage here.
Finally, lead time. Lead time is one of the for metrics tracked by the DORA program’s research into software development teams. The book Accelerate, written by the founders of the DORA research program, goes into much more depth than I can fit here, so I’m going to briefly summarize just this one aspect.
Lead time is the amount of time it takes to go from code being committed to that same code being live in production. If you can make a change and get it deployed into production in just a few minutes, you will have a completely different experience developing your application than if it takes hours or days. The DORA research found that small lead times is one of the biggest predictors of software projects being successful.
The overall, main finding of the DORA research project is that conventional wisdom of going slowly and carefully is exactly backwards—the teams and projects with the least errors and rollbacks are the teams that deploy the fastest and the most frequently. If you’re already operating a larger or slower application in production, the biggest advice that I have is to reduce the size of each change, and make rolling out each change as fast as you possibly can.
The beginning of a project is by far the easiest time to set up the standard automations that you plan to use going forward. I strongly recommend setting up completely automatic testing and deployment. With GitHub Actions and modern hosting platforms, you can expect new commits to be tested and fully deployed to production within 5 minutes. That’s a fantastic starting point to use as a base for future expansion, as your application and team grows.
Now that I’ve filled your heads with more ideas than you can probably remember, let’s quickly review and then briefly discuss an overall strategy that you can use whenever you are trying to operate a production application. The big concerns after you deploy your app are: Errors, Data, Speed, Security, and Lead Time. Use those categories to review proposed changes, and look for issues you might have missed. Will the proposed change impact your ability to monitor errors? Back up user data? Respond to requests quickly? Keep your application secure? Ship changes quickly?
By keeping those categories of concern in mind, you are already better prepared to operate a production deployment than the vast majority of Rails developers. If the thought of working with those concerns is interesting or exciting to you, you probably have a bright future in DevOps or SRE. If the thought of working with those concerns fills you with unspeakable dread, you probably want to stick to bigger teams where someone else is available to handle operations and deployment.
If your team could use a boost while handling everything we’ve talked about today, you can get that support. I work for Spinel Cooperative, with developers from the core teams of Rails, Hotwire, RubyGems, and more. We would love to give your team all the advantages of 20 years spent building, deploying, and operating Ruby and Rails. Come say hi after the talk, or drop us an email at hello@spinel.coop.
In the end, will listening to all the advice in this talk mean your app never goes down? Unfortunately, probably not. Downtime is something that comes for us all, and usually includes some aspect that is completely unexpected or outside of our control. Instead, this advice will make you prepared. You’ll be prepared to recover from downtime, and prepared to add more protections in the future as you learn the particular issues your application needs to defend against.
Ultimately, that’s the best any of us can do, and I wish you all good luck with your future deployments.
]]>While we know that Ruby Central had no right to act the way they did, it is nevertheless clear to us that the Ruby community will be better off if the codebase, maintenance, and legal rights to RubyGems and Bundler are all together in the same place.
To bring this about, we are prepared to transfer our interests in RubyGems and Bundler to Matz, end the dispute over the GitHub enterprise account, 2 GitHub organizations, and 70 repositories, and hand over all rights in the Bundler logo and Bundler name, including the trademark applications in the US, EU, and Japan.
Once we have entered into a legal agreement to settle any legal claims with Ruby Central and transfer all rights to Matz, the former maintainers will step back entirely from the RubyGems and Bundler projects, leaving them fully and completely to Matz, and by extension to the entire Ruby community.
Although Ruby Central’s actions were not legitimate, our commitment to the Ruby community remains strong. We’re choosing to focus our energy on projects to improve Ruby for everyone, including rv, Ruby Butler, jim, and gem.coop.
Signed,
The former maintainers: André, David, Ellen, Josef, Martin, and Samuel
jj part 3: workflows
Just like git, jj offers tiers of configuration that layer on top of one another. Every setting can be set for a single repo, for the current user, or globally for the entire system. Just like git, jj offers the ability to create aliases, either as shortcuts or by building up existing commands and options into new completely new commands.
Completely unlike git, jj also allows configuring revset aliases and default templates, extending or replacing built-in functionality. Let’s look at the ways it’s possible to customize jj via configurations. We’ll cover basic config, custom revsets, custom templates, and custom command aliases.
Let’s start with some configuration basics. You can globally configure jj to change your name and email based on a path prefix, so you don’t have to remember to set your work email separately in each work repo anymore.
[[--scope]]
--when.repositories = ["~/work"]
[--scope.user]
email = "me@work.domain"
Or perhaps you want jj to wait for your editor if you are writing a commit message, but you don’t want jj to wait for your editor to exist if you are editing your jj configuration file. You can ensure that using a scope.
ui.editor = "code -w"
[[--scope]]
--when.commands = ["config"]
[--scope.ui]
ui.editor = "code"
I also highly recommend trying out multiple options for formatting your diffs, so you can find the one that is most helpful to you. A very popular diff formatter is difftastic, which provides syntax aware diffs for many languages. I personally use delta, and the configuration to format diffs with delta looks like this:
[[--scope]]
--when.commands = ["diff", "show"]
[--scope.ui]
pager = "delta"
diff-formatter = ":git"
Another very impactful configuration is which tool jj uses to handle interactive diff editing, such as in the jj split or jj squash -i commands. While the default terminal UI is pretty good, make sure to also try out Meld, an open source GUI.
[ui]
diff-editor = "meld" # or vimdiff, vscode, etc
In addition to changing the diff editor, you can also change the merge editor, which is the program that is used to resolve conflicts. Meld can again be a good option, as well as any of several other merging tools.
[ui]
merge-editor = "meld" # or vimdiff, vscode, mergiraf etc
Tools like mergiraf provide a way to attempt syntax-aware automated conflict resolution before handing off any remaining conflicts to a human to resolve. That approach can dramatically reduce the amount of time you spend manually handling conflicts.
You might even want to try FileMerge, the macOS developer tools built-in merge tool. It supports both interactive diff editing and conflict resolution.
[merge-tools.filemerge]
program = "open"
edit-args = ["-a", "FileMerge", "-n", "-W", "--args",
"-left", "$left", "-right", "$right",
"-merge", "$output"]
merge-args = ["-a", "FileMerge", "-n", "-W", "--args",
"-left", "$left", "-right", "$right",
"-ancestor", "$base", "-merge", "$output",]
Just two more configurations before we move on to templates. First, the default subcommand, which controls what gets run if you just type jj and hit return. The default is to run jj log, but my own personal obsessive twitch is to run jj status constantly, and so I have changed my default subcommand to status, like so:
[ui]
default-command = ["status"]
The last significant configuration is the default revset used by jj log. Depending on your work patterns, the multi-page history of commits in your current repo might not be helpful to you. In that case, you can change the default revset shown by the log command to one that’s more helpful. My own default revset shows only one change from my origin. If I want to see more than the newest change from my origin I use jj ll to get the longer log, using the original default revset. I’ll show that off later.
[revsets]
log = "(trunk()..@):: | (trunk()..@)-"
While the jj template docs are a great reference, they don’t do very much to show off what’s possible by using templates, so we’ll show some examples.
The first and most obvious template is the jj log template, which controls how each change is rendered in the log output. The default template is named builtin_log_compact, and jj comes with a few pre-built template options for the log view, like builtin_log_detailed and builtin_log_oneline. You can see them all by running jj log -T.
Use jj log -T NAME to try them out and see how they look. If you want to experiment with your own custom log formats, you can provide a template string instead of the name of an existing template. Here’s an example inline template that prints out just the short change ID, a newline, and then the change description:
jj log -T 'change_id.short() ++ "\n" ++ description'
Try out the various documented template properties yourself! Once you’re happy with a template that you’ve tested, you can add it to your config with a name, and then use it by name.
Here’s a more complicated example, adapted from @marchyman in the jj Discord, with several of the elements that we’ve discussed so far. This example changes the default command, adding extra options. It also uses a named revset alias, and a named template alias.
[ui]
default-command = ["log", "-T", "log_with_files", "--limit" "7"]
[revset-aliases]
'recent_work' = 'ancestors(visible_heads(), 3) & mutable()'
[template-aliases]
log_with_files = '''
if(root,
format_root_commit(self),
label(if(current_working_copy, "working_copy"),
concat(
format_short_commit_header(self) ++ "\n",
separate(" ",
if(empty, label("empty", "(empty)")),
if(description,
description.first_line(),
label(if(empty, "empty"), description_placeholder),
),
) ++ "\n",
if(self.contained_in("recent_work"), diff.summary()),
),
)
)
'
The named template recreates the regular template from log, and uses a revset filter to include the list of changed files in changes that are both mutable (that is, not yet pushed) and also within 3 commits of the end of a branch. By showing up to 7 changes, but the file list for up to 3 mutable changes, the log output becomes more useful, reminding you what files have been changed in the most recent commits that you might want to push.
One more template you might want to adjust is the default description, shown when running jj commit or jj desc for a change that does not yet have a description. If you don’t use a VCS GUI, it can be helpful to see the diff of what is being committed at the same time as you write the commit message. In git, that meant running git commit --verbose, but in jj that means adjusting the default description. The jj config docs provide an example template that will replicate that effect, and show you the diff while you write the message.
Building on the earlier section where we talked about jj log, creating your own revset aliases is a powerful way to construct views tailored to your personal needs.
A built-in revset alias we can use to illustrate this is immutable(). In the same way that git requires --force to push over an existing remote commit, jj requires --ignore-immutable to edit a commit matched by immutable().
(Incidentally, I believe this arrangement is also an example of the way jj’s design is an improvement on git. Instead of deciding to overwrite published commits during a push, you are forced to decide much earlier, during the edit itself, if you are okay with changing a published commit. Anyway, back to revset aliases.)
The default immutable_heads() revset is present(trunk()) | tags() | untracked_remote_bookmarks(), which composes four other revsets together. Let’s look at each one. The trunk() revset is simply the primary branch, whether it is named main or master, wrapped in present() to remove it if none of those branches exist. The tags() revset is every change that has been given a tag. The untracked_remote_bookmarks() revset is exactly what it sounds like: any branch provided by the remote that you have not manually opted in to tracking locally (which is what you would do if you are working on the branch). All three revsets are combined into one overall list with the | operator. Those heads are then used to construct the full list of immutable commits, which is every ancestor of those heads.
Now that you know how that works, we can change it. For example, perhaps you want the same immutability rules that git provides, where commits are immutable once they have been pushed to any remote at all. In that case, you could add this to your config file:
[revset-aliases]
"immutable_heads()" = "present(trunk()) | tags() | remote_bookmarks()"
With that configuration, jj will extrapolate that it cannot change any commits on the primary branch, all the commits leading up to a tag, and all commits leading up to a named branch in the remote. If you use this revset, jj will stop you from changing commits once you have pushed them to a branch, since you told it to make those immutable.
With this power at your disposal, you can change the default revset shown when you run jj log, or you can create your own named revsets for your own purposes. You can see my revset aliases in my dotfiles, and read more about the default aliases in the jj docs.
Okay. Now we can talk about command aliases. First up, the venerable tug. In the simplest possible form, it takes the closest bookmark, and moves that bookmark to @-, the parent of the current commit.
tug = ["bookmark", "move", "--from", "heads(::@- & bookmarks())", "--to", "@-"]
What if you want it to be smarter, though? It could find the closest bookmark, and then move it to the closest pushable commit, whether that commit was @, or @-, or @---. For that, you can create a revset for closest_pushable, and then tug from the closest bookmark to the closest pushable, like this:
[revset-aliases]
'closest_pushable(to)' = 'heads(::to & mutable() & ~description(exact:"") & (~empty() | merges()))'
[aliases]
tug = 'bookmark move --from "heads(::@ & bookmarks())" --to "closest_pushable(@)"'
Now your bookmark jumps up to the change that you can actually push, by excluding immutable, empty, or descriptionless commits.
What if you wanted to allow tug to take arguments, for those times when two bookmarks are on the same change, or when you actually want to tug a different bookmark than the closest one? That’s also pretty easy, by adding a second variant of the tug command that takes an argument:
tug = ["util", "exec", "--", "sh", "-c", """
if [ "x$1" = "x" ]; then
jj bookmark move --from "closest_bookmark(@)" --to "closest_pushable(@)"
else
jj bookmark move --to "closest_pushable(@)" "$@"
fi
""", ""]
This version of tug works just like the previous one if no argument is given. But if you do pass an argument, it will move the bookmark with the name that you passed instead of the closest one.
How about if you’ve just pushed to GitHub, and you want to create a pull request from that pushed bookmark? The gh pr create command isn’t smart enough to figure that out automatically, but you can tell it which bookmark to use:
pr = ["util", "exec", "--", "bash", "-c", """
gh pr create --head $(jj log -r 'closest_bookmark(@)' -T 'bookmarks' --no-graph | cut -d ' ' -f 1)
"""]
Just grab the list of bookmarks attached to the closest bookmark, take the first one, pass it to gh pr create, and you’re all set.
What if you just want single commands that let you work against a git remote, with defaults tuned for automatic tugging, pushing, and tracking? I’ve also got you covered.
init = ["util", "exec", "--", "bash", "-c", """
jj git init --colocate
# only track origin branches, not upstream or others
jj bookmark track 'glob:*@origin'
"""]
Use jj init to colocate jj into this git repo, and then track any branches from upstream, like you would get from a git clone.
pull = ["util", "exec", "--", "bash", "-c", """
# Find the closest bookmark
closest="$(jj log -r 'closest_bookmark(@)' \
-n 1 -T 'bookmarks' --no-graph | cut -d ' ' -f 1)"
# Remove the trailing * from the name if there is one
closest="${closest%\\*}"
# Now fetch from the git remote
jj git fetch
# If the closest bookmark still exists, rebase on it (else trunk)
jj log -n 1 -r "${closest}" 2>&1 > /dev/null \
&& jj rebase -d "${closest}" || jj rebase -d 'trunk()'
# Show the new state of things after the pull
jj log -r 'stack()'
"""]
Then, you can jj pull to find the closest bookmark to @, do a git fetch, rebase your current local commits on top of whatever just got pulled, and then show your new stack. When you’re done, just jj push.
push = ["util", "exec", "--", "bash", "-c", """
# Check to see if we can tug a bookmark to @
tuggable="$(jj log -r 'closest_bookmark(@)..closest_pushable(@)' \
-T '"n"' --no-graph)"
# If we can, tug that bookmark as close to @ as possible
[[ -n "$tuggable" ]] && jj tug
# Now find the closest thing that we can push to `origin`
pushable="$(jj log -r 'remote_bookmarks(remote=origin)..@' \
-T 'bookmarks' --no-graph)"
# If we have something to push, run `jj git push`
[[ -n "$pushable" ]] && jj git push || echo "Nothing to push."
# Now that we have pushed, find the closest bookmark and remove *
closest="$(jj log -r 'closest_bookmark(@)' -n 1 -T 'bookmarks' \
--no-graph | cut -d ' ' -f 1)"
closest="${closest%\\*}"
# Check to see if that bookmark is already tracking origin
tracked="$(jj bookmark list -r ${closest} -t \
-T 'if(remote == "origin", name)')"
# If that bookmark isn't tracking origin, start to track origin
[[ "$tracked" == "$closest" ]] \
|| jj bookmark track "${closest}@origin"
"""]
This push handles looking for a tuggable bookmark, tugging it, doing a git push, and making sure that you’re tracking the origin copy of whatever you just pushed, in case you created a new branch.
For another perspective on jj configuration, partly overlapping with this post, check out my JJ Con talk, stupid jj tricks.
You can also try reading some jj config files directly, like my jj config, or thoughtpolice’s jj config, or pksunkara’s jj config.
Hopefully this tour through jj configuration options has revealed some ways that jj can be used to do more than was possible with only git. Next time, we’ll focus on the ways that jj goes beyond git, offering things that were impractical or even impossible before.
]]>jj part 2: commands
Now that you hopefully have an idea of how to operate jj, let’s look at the commands you need to get work done in jj. One great aspect of jj layering on top of git repos is that the git repo is still there underneath, and you can use any git command exactly like you usually would if there’s anything missing from your jj workflows.
The flow to create and send a PR will probably look pretty familiar: use jj git clone to get a copy of the repo, make your changes, use jj commit to create your new commits. When you’re ready, use jj bookmark set NAME to give your changes a name and jj git push to create a new branch on the remote. Use GitHub.com or gh pr create --head NAME to open the PR.
If you amend the commits in your PR, you can force-push the new commits with jj git push. If you add new changes on top, you’ll need to jj bookmark set NAME to update the bookmark to the latest change before you jj git push again.
That’s the whole flow! Congratulations on migrating from git to jj for your everyday work.
If using bookmark set all the time gets tedious, there’s a community alias named jj tug that finds the closest bookmark and moves it to the closest pushable change. I personally wrote an alias for myself named jj push that I use to handle pushing new changes to existing remote branches. We’ll talk about those aliases in the next major section, which is about configuring jj.
One situation I often find myself in is working on two (or even more) pull requests at the same time. With the powerful commit-editing primitives provided by jj, there are at least two (and probably more) ways to structure this kind of parallel work.
The first option is what I think of as merge-based: create a merge commit that unifies the tips of your two or more branches using jj new -d A -d B, do your work, and create new commits with jj split or jj commit. Then, rebase those commits using jj rebase -r @- --insert-before A or the like, moving the new commits backwards into one of the PR branches. This is the same as the “megamerge” strategy described above, but it works just as well with two branches.
The second option is to liberally rebase every branch on top of each other, creating a completely linear history where PR #4 contains PR #3, which also contains PR #2, which also contains PR #1. Since jj uses change IDs to keep track of changes as their commits are amended or rebased, you can rebase the entire chain on top of new commits to main. Your bookmarks will stay in the same place, and you can jj git push to update each remote branch. Any time one of the PRs lands, you rebase your full chain on top of the new main and resume work where you left off.
If you want to work on multiple branches at once, you will probably also find the articles Jujutsu Merge Workflow and Jujutsu Megamerges and jj absorb interesting.
There are many new workflows that jj users have already developed, and this brief overview is just the tip of the iceberg. The jj docs include a section on using jj with GitHub or GitLab, and there are some great reflections on different workflows in the blog posts Jujutsu VCS Introduction and Patterns, Git experts should try Jujutsu, and jj tips and tricks.
Next up, we’re going to talk about configuring jj. Want to use a diff tool? A merge tool? Add your own commands? Optimize your day to day work? We’ve got options.
Continue with jj part 4: configuration.
This version dramatically expands support for Rubies, shells, and architectures.
Rubies: we have added Ruby 3.3, as well as re-compiled all Ruby 3.3 and 3.4 versions with YJIT. On Linux, YJIT increases our glibc minimum version to 2.35 or higher. That means most distro releases from 2022 or later should work, but please let us know if you run into any problems.
Shells: we have added support for bash, fish, and nushell in addition to zsh.
Architectures: we have added Ruby compiled for macOS on x86, in addition to Apple Silicon, and added Ruby compiled for Linux on ARM, in addition to x86.
Special thanks to newest member of the maintainers’ team @adamchalmers for improving code and tests, adding code coverage and fuzzing, heroic amounts of issue triage, and nushell support. Additional thanks are due to all the new contributors in version 0.2, including @Thomascountz, @lgarron, @coezbek, and @renatolond.
To upgrade, run brew install rv, or check the release notes for other options.
First, and most importantly: I was a primary operator of RubyGems.org, securely and successfully, for over ten years. Ruby Central does not accuse me of any harms or damages in their post, in fact stating “we have no evidence to indicate that any RubyGems.org data was copied or retained by unauthorized parties, including Mr. Arko.”
The actions I took during a time of great confusion and uncertainty (created by Ruby Central!) were careful, specific, and aimed to defend both Ruby Central the organization and RubyGems.org the service from potential threats.
The majority of the team, including developers in the middle of paid full-time work for Ruby Central, had just had all of their permissions on GitHub revoked. And then restored six days later. And then revoked again the next day. Even after the second mass-deletion of team permissions, Marty Haught sent an email to the team within minutes, at 12:47pm PDT, saying he was (direct quote) “terribly sorry” and “I messed up”. Update: Added email timestamp.
The erratic and contradictory communication supplied by Marty Haught, and the complete silence from Shan and the board, made it impossible to tell exactly who had been authorized to take what actions. As this situation occurred, I was the primary on-call. My contractual, paid responsibility to Ruby Central was to defend the RubyGems.org service against potential threats.
Marty’s final email clearly stated “I’ll follow up more on this and engage with the governance rfc in good faith.”. Just a few minutes after that email, at 1:01pm PDT, Marty also posted a public GitHub comment, where he agreed to participate in the proposed governance process and stated “I’m committed to find the right governance model that works for us all. More to come.” Update: screenshot of comment removed and replaced with link, since the comment appears to still be visible (at least to logged out users) on GitHub.
Given Marty’s claims, the sudden permission deletions made no sense. Worried about the possibility of hacked accounts or some sort of social engineering, I took action as the primary on-call engineer to lock down the AWS account and prevent any actions by possible attackers. I did not change the email addresses on any accounts, leaving them all owned by a team-shared email at rubycentral.org, to ensure the organization retained overall control of the accounts, even if individuals were somehow taking unauthorized actions.
Within a couple of days, Ruby Central made an (unsigned) public statement, and various board members agreed to talk directly to maintainers. At that point, I realized that what I thought might have been a malicious takeover was both legitimate and deliberate, and Marty would never “fix the permissions structure”, or “follow up more” as he said.
Once I understood the situation, I backed off to let Ruby Central take care of their “security audit”. I left all accounts in a state where they could recover access. I did not alter, or try to alter, anything in the Ruby Central systems or GitHub repository after that. I was confident, at the time, that Ruby Central’s security experts would quickly remove all outside access.
My confidence was sorely misplaced.
Almost two weeks later, someone asked if I still had access and I discovered (to my great alarm), that Ruby Central’s “security audit” had failed. Ruby Central also had not removed me as an “owner” of the Ruby Central GitHub Organization. They also had not rotated any of the credentials shared across the operational team using the RubyGems 1Password account.
I believe Ruby Central confused themselves into thinking the “Ruby Central” 1Password account was used by operators, and they did revoke my access there. However, that 1Password account was not used by the open source team of RubyGems.org service operators. Instead, we used the “RubyGems” 1Password account, which was full of operational credentials. Ruby Central did not remove me from the “RubyGems” 1Password account, even as of today.
Aware that I needed to disclose this surprising access, but also aware that it was impossible for anyone except former operators to exploit this security failure, I immediately wrote an email to Ruby Central to disclose the problem.
Here is a copy of my disclosure email, in full.
From: André Arko <andre@arko.net>
Subject: Re: RubyGems.org access
Date: September 30, 2025 at 10:23:12 AM PDT
To: Marty Haught <marty@rubycentral.org>
Hi Marty,
It has come to my attention that despite the statements in [your] email, I have had uninterrupted access to RubyGems.org production environments from September 18 until today, September 30, via the root credentials of the Ruby Central AWS account, as well as continued and ongoing access to the full feed of production alerts and logs in DataDog.
It seems that the only permissions I have had removed are from the GitHub organization named "rubygems", which as you know is unrelated to the RubyGems.org production access you mention in your email.
I have also noticed I am still, as of September 30, the owner of the GitHub organizations named "rubycentral" and "rubytogether".
I am unable to transfer the HelpScout or PagerDuty accounts, as you have disabled my andre@rubygems.org Google account.
Please advise as to your desired resolution of this situation.
Thank you,
André Arko
Ruby Central did not reply to this email for over three days.
When they finally did reply, they seem to have developed some sort of theory that I was interested in “access to PII”, which is entirely false. I have no interest in any PII, commercially or otherwise. As my private email published by Ruby Central demonstrates, my entire proposal was based solely on company-level information, with no information about individuals included in any way. Here’s their response, over three days later.
From: Marty Haught <marty@rubycentral.org>
Subject: Re: RubyGems.org access
Date: October 3, 2025 at 6:54:01 PM MDT
To: André Arko <andre@arko.net>
Hi André,
Please confirm that you cannot access the Ruby Central AWS root account credentials, either through the console or by access keys.
In addition, please confirm whether you are in possession of any RubyGems.org production data, including, but not limited to, server logs, access logs, PII, or other organizational data.
Thank you,
Marty
In addition to ignoring the (huge) question of how Ruby Central failed to secure their AWS Root credentials for almost two weeks, and appearing to only be aware of it because I reported it to them, their reply also failed to ask whether any other shared credentials might still be valid. There were more.
From: André Arko <andre@arko.net>
Subject: Re: RubyGems.org access
Date: October 5, 2025 at 11:59:35 AM PDT
To: Marty Haught <marty@rubycentral.org>
Hi Marty,
Thanks for letting me know you got my email disclosing my unintended access. I’m concerned that security must not be a very high priority for Ruby Central since no one acknowledged my disclosure for more than three days, but I appreciate the confirmation.
As far as I can tell, I can no longer access the Ruby Central AWS root account either through the console or via access keys.
I confirm I did not download or save any production data after your email of September 18, including server logs, access logs, PII, or other organizational data.
However, while checking AWS credentials in order to write this email, I discovered that several other service credentials have not been rotated, and are still valid for production AWS access. That means both myself and the other former operators all still have access to AWS via those previously-shared credentials.
I would appreciate it if you could answer the request from my first email, and reply with your desired resolution for this remaining unintended production access, as well as the GitHub organization ownership.
Thanks,
André
Unbeknownst to me, while I was answering Marty’s email in good faith, Ruby Central’s attorney was sending my lawyer a letter alleging I had committed a federal crime, on the theory that I had “hacked” Ruby Central’s AWS account. On the contrary, my actions were taken in defense of the service that Ruby Central was paying me to support and defend.
With my side of the story told, I’ll leave it to you to decide whether you think it’s true that “Ruby Central remains committed to transparent, responsible stewardship of the RubyGems infrastructure and to maintaining the security and trust that the Ruby ecosystem depends on.”
]]>The new server’s governance policies are being prepared in coordination with Mike McQuaid of Homebrew, and will be released later this week.
The current versions of RubyGems and Bundler work with this new server already, and any Ruby developer is welcome to switch to using this new server immediately.
We have exciting plans to add new features and functionality in the coming days. Join us!
]]>jj part 1: what is it
Now, let’s take a look at the most common jj commands, with a special focus on the way arguments are generally consistent and switches don’t hide totally different additional commands.
The log command is the biggest consumer of revsets, which are passed using -r or --revisions. With @, which is the jj version of HEAD, you can build a revset for exactly the commits you want to see. The git operator .. is supported, allowing you to log commits after A and up to B with -r A..B, but that’s just the start. Here’s a quick list of some useful revsets to give you the flavor:
@- the parent of the current commitkv+ the first child of the change named kv..A & ..B changes in the intersection of A and B’s ancestors~description(glob:"wip:\*") changes whose message does not start with wip:, because tilde negates a revsetheads(::@ & mutable() & ~description(exact:"") & (~empty() | merges())) the closest “pushable” change, meaning the nearest ancestor of @ that is mutable (by default mutable means “not in the main/trunk branch”), that has some description set, and that either has some changes or is a merge commit. (Some jj merge commits can be empty, if there were no conflicts.)Using the jj config file, you can give any revset an alias, and then use that alias. I use closest_pushable(@) quite a bit, especially when naming branches and pushing.
For a full review of everything that’s possible with revsets, check out the revset documentation and the blog post Understanding Revsets for a Better JJ Log Output.
The functionality of git commit is broken up into four separate jj commands. You use new to create a new empty child change, defaulting to @, and edit it. The desc command lets you set the description (or message) on a given change. The commit command works like git, but is effectively the same as jj desc && jj new. You use edit to re-open an existing change for amending, and split to interactively select a diff to break out into a second change. These are all common git workflows, done by using flags or multiple git commands, made direct and straightforward single commands in jj.
What if using checkout and reset to roll back either files or full commits had clearer names?
If you want to get back a file from a previous change, you can use restore. Specify which change you want to bring back, and also provide a file name or glob to limit the restoration to specific files.
Where you might have previously used git reset or git checkout to manipulate which commits are included in the current branch, you can now use abandon to remove entire changes from your history. Without any arguments it will remove @, the working commit, which is similar to git reset --hard. With arguments, abandon will remove all changes in the given revset from the local history.
Bookmarks are jj’s alternative to named git branches, and can be set up to automatically track a branch in a git remote. While compatibility with git branches is nice, names aren’t required by jj’s model. You can push your current unnamed change instantly with jj git push --change @, and jj will use the change ID (which stays the same across amends and rebases) as the git branch name. Now you don’t have to think of a good name for your branch before you can work on it (or push it!).
For more detail comparing and contrasting bookmarks to branches, I recommend the post Understanding Jujutsu bookmarks.
It does what you would expect based on git, but the defaults are different than you might expect. Unless you configure the git.fetch and git.push settings, jj will only push to or fetch from origin. To operate on another remote, pass --remote NAME. To operate on all remotes, use glob:* as the remote name.
The rebase command works like you would expect, but better. You can rebase a single change to a different place with jj rebase -r id --insert-before A, or rebase a change and all it’s descendants with jj rebase -s id --insert-after B. You can even rebase an entire branch automatically with jj rebase -b @ --destination C, moving every ancestor of @ that is not an ancestor of C into a new chain of commits descending from C. I did all of these constantly in git, and it’s much more involved.
The squash command is just a clear, single command for the common git operation where you move a diff into a commit or move a diff out of a commit, by change ID and/or filename.
The git rebase and merge commands (also including apply-patch, cherry-pick, and others) are all a bit special because they can create conflicts that have to be resolved before git will allow the commit to be… committed. This is the other half of the magic of jj: your new commit just holds any conflicts inside it. It’s impossible to lose work in a merge disaster because everything is always committed. You can resolve conflicts immediately, after other merges, or never! The results are always immediately stored, no matter how complete or incomplete your resolution is at the time.
Thanks to this feature, you don’t need a dedicated merge command—any new change can have however many parents you want, regardless of conflicts. It’s just as valid to jj new A B C D E as it is to jj new A. One pattern that is common in jj but was miserable in git is to create a “megamerge” combining all your current work branches. All editing happens on top of the megamerge, and you move individual changes backwards into a specific branch as you decide where to put them. Compared to git, it feels like magic.
There are many jj commands that have no analogous git command. Some real standouts include jj absorb, jj parallelize, and jj undo. We’ll talk more about those commands in a future post about jj beyond git.
The previously mentioned jj cheat sheet PDF has a second page, containing a quick summary of each command, what it does, and the arguments it accepts.
Now that we have talked about commands, next up is workflows! How can you use jj to work on a pull request? How can you work on multiple branches or PRs at the same time?
Continue with jj part 3: workflows.
The full series also includes: part 4: configuration
]]>For the last ten years or so of working on Bundler, I’ve had a wish rattling around: I want a bigger, better dependency manager. It doesn’t just manage your gems, it manages your ruby versions, too. It doesn’t just manage your ruby versions, it installs pre-compiled rubies so you don’t have to wait for ruby to compile from source over and over. And more than all of that, it makes it completely trivial to run any script or tool written in ruby, even if that script or tool needs a different ruby and gems than your application does.
For the entire ten years of daydreaming, I’ve been hoping someone else would build it and I could just use it. Then I discovered that someone did build it… but for Python. It’s called uv, and almost exactly one year ago version 0.3 shipped with all the features I had wished for, and even more that I hadn’t thought to wish for.
At this point, I’ve been using uv for almost a year and every time I use a project written in Python, the experience is delightful. Not only can you run a command directly out of any package that isn’t even installed, you can run a command that requires a python you don’t have installed, and uv takes care of installing the right python, installing the right packages, and running your command, in just a second or two.
Whether you want to run a CLI tool, a webapp, or a random script, uv always ensures the environment is correct as part of running the command. No more installing a new package version only to realize later you broke something old, no more setting up dependencies manually only to have the script running inside cron silently break later.
Earlier this year, my long time consulting job disappeared and I found myself looking for something to replace it. One of my ideas was to start a company inspired by Geomys in the Go language, offering expert advice from open source maintainers, but the idea felt weak to me without a “spotlight” project to show off our expertise.
In July of this year, I finally realized that these two ideas could go together extremely well—the company can show our expertise by building this developer tool, and clients paying for our advice to solve their problems can ensure we are able to support and expand the tool.
I talked to some Ruby friends about the idea, and it resonated with them, so we started working on both the company and the open source project. Today, Spinel Cooperative has a website at spinel.coop, and rv has a website at rv.dev. The team has expanded, and includes notable RubyGems and Bundler contributors Samuel Giddins and David Rodriguez, notable Rails contributors Kasper Timm Hanson and Sam Stephenson, who is also the original creator of rbenv and ruby-build.
Our goal is a completely new kind of management tool, where you don’t need to install rvm and then some ruby and then update rubygems and bundler and then bundle install your gems—you just run your command, and everything is handled. Not a version manager, or a dependency manager, but both of those things and much more.
With that vision in place, we were now faced with a very practical question. What can we build that would be useful right away? We landed on precompiled rubies for development work as the most useful place to start, and got to work.
We’re using Rust to build rv, for two reasons. The obvious reason is that Rust produces very fast results, which is also why our biggest inspiration uv is written in Rust. The less obvious reason is based on years of trying to onboard new contributors to Bundler and RubyGems—it turns out if you are a Ruby developer, you unfortunately don’t (yet) know the subset of Ruby that we are forced to use for Bundler and RubyGems.
There are two major things that basically every Ruby program does that you can’t do if you are managing gems. First, you can’t use any gems. If you want to use code that’s inside a gem, you need to copy that code wholesale into Bundler or RubyGems, and then you need to constantly update it anytime that gem has any changes. Second, you can’t use anything with native extensions, ever. JSON gem? Psych gem for YAML? Completely impossible, because Bundler and RubyGems need to be installable even if there is no compiler present.
So with those constraints in mind, and with a clear goal in mind of a tool so fast you normally can’t even tell it’s running, we settled on Rust, and started building a CLI. I’ve used Rust for smaller personal projects in the past, but never created a full CLI tool. I am happy to report that the clap library for creating CLIs in Rust is great, and recommend it to anyone who might be interested.
The next piece that we needed was precompiled Rubies. There are a few big projects out there compiling Ruby in advance, mostly for use on servers. The setup-ruby GitHub action and the official Ruby docker images are both based on the ruby-build project originally started as part of rbenv.
Unfortunately, those existing precompiled Ruby versions aren’t usable for our needs because they aren’t statically compiled and because they aren’t relocatable. Statically compiled (as opposed to dynamically compiled) means that Ruby copies the code from a shared library into its own binary.
Show of hands… have any of you ever had trouble compiling Ruby because of OpenSSL? Okay, put your hands down. Now, how many of you have had an already-installed Ruby suddenly stop working because of OpenSSL, and you had to install it again? Good news, rv fixes both of those problems by putting the OpenSSL inside the Ruby, so they can never get separated.
There is a tradeoff here—if there is a critical security flaw in OpenSSL, we will need to compile Ruby again to include the critical security update. The first reason we are okay with this tradeoff is that OpenSSL doesn’t have huge security issues very often. The second reason we are okay with this is that your production servers are probably using the official Ruby docker images and not Ruby installed by rv, so it’s even less of a concern.
In the end, the closest existing system we were able to build on top of was Homebrew’s portable-ruby project. That’s the system Homebrew uses to build the Ruby install that Homebrew itself runs on. The Homebrew team built some excellent infrastructure for building a statically linked Ruby, and even added the changes needed to make sure that Ruby could be relocated.
Since Homebrew needs to be able to install into /usr/local on x86, but /opt/homebrew on Apple Silicon, and into any user’s home directory for Linuxbrew, they need to be able to take a single precompiled Ruby and put it in any location on disk. That’s another one of the requirements that isn’t met by the setup-ruby or Docker image Rubies—if you move them to another directory, they stop working.
Using Homebrew’s portable-ruby as a base, we were able to start with macOS ARM and Ubuntu x86, add Ubuntu on ARM, and then build every version in the Ruby 3.4.x series. After a few weeks of work, we had some initial functionality working. rv could switch between installed Ruby versions in zsh, but most importantly it could install precompiled Ruby 3.4.x on macOS and Ubuntu in one second flat. Yes, you heard that right. rv ruby install 3.4.5. Wait 1 second. Done. You can run Ruby commands now.
With that proof of concept complete, we announced version 0.1. People got very excited! It was fantastic to see how many people were excited by the vision for a new, fast tool for Ruby development.
It’s been a few weeks since that 0.1 release, and we have been hard at work. We’ve expanded the team to include community contributors, merged pull requests, and compiled more Rubies than ever.
When 0.2 is released, in the very near future, it will include support for not just zsh, but bash, fish, and nushell. We have also added support for macOS on x86, meaning we now fully support x86 and ARM on both macOS and Linux. Finally, the precompiled Ruby versions available will expand to include all of Ruby 3.3 as well as 3.4. Just to top all of that off, every version of Ruby will have YJIT built in.
Our short-term plans include finishing support for Ruby 3.2, adding rubies that work with musl libc on Linux, and testing on more Linux distributions. Our longer-term plans including improving the way gems are compiled, so that installing your entire application and all of its gems can happen in just a few seconds.
We want to live in a future where anyone can run a Ruby command, or tool, or application in seconds (or less!). We’re going to build that future, for ourselves and for everyone else.
]]>