Brioche

Brioche Project Update - August 2024

Published on

By Kyle Lacy

So, it’s been about two months since the initial public release of Brioche, so I thought it was about time to share what’s been going on with the project! I quite like the newsletter-style updates that Rust and Dolphin put out regularly, so I think I’ll start doing something similar for Brioche (expect ~monthly updates)

Brioche releases

Brioche v0.1.1 was released in early June, which helped smooth out some of the kinks from v0.1.0. The changelog includes all the details, but to give a few highlights:

I even included a subcommand to update Brioche itself, but uhhh… it’s broken, so for now, you’ll need to follow the installation instructions again to upgrade. Also unfortunately, I didn’t catch this issue before v0.1.1 was released, so it’s still broken and the next release will also require a manual upgrade… oops

Package updates

During the initial release, there were only 10 packages available: ca_certificates, curl, jq, miniserve, nodejs, rust, plus the std package and a few miscellaneous ones (hello_world, typer, smol_toml)

Now, there are 38, almost 4x as many as during the original launch! Here’s what’s available now:

Massive kudos for these packages go to @jaudiger and @asheliahut, who opened 31 and 7 Pull Requests, respectively!

There were also several breaking changes made to Rust, NodeJS, and Go, to make building packages more consistent. See the PRs brioche-packages#65 and brioche-packages#67 for an overview of the changes.

std updates

The std package has also seen quite a few changes. Note that it’s still pretty volatile, so keep an eye on the changelog to see how it evolves.

Since the initial release, there have been quite a few changes! Here’s the full list of changes since the initial release, but here are the highlights:

Brioche core updates

I was hoping to have a v0.1.2 release ready to go before publishing the first project update, but alas, it’s not ready to go quite yet…

…but that also means there are a few goodies in the main branch that you can look forward to for the next release!

Updates to several subcommands (fmt, check, publish, install) so they can take more than one package at a time. When working with multiple Brioche projects (say, if you’re contributing a new package), you can now save time by passing the -p or -r flag more than once! Once again, huge thanks to @jaudiger for contributing these changes!

Add support for “locked downloads” with Brioche.download expressions. Normally when downloading something with Brioche, you need to provide the download hash explicitly in code. This has long led to an awkward dance where you need to get the URL, download it yourself first, get the hash, then paste it in the code. Well, as long as the URL is static in your source code, you’ll no longer need to do this! Just change from this:

// Old way, need to specify the hash manually
const source = std
  .download({
    url: "https://github.com/jqlang/jq/releases/download/jq-1.7.1/jq-1.7.1.tar.gz",
    hash: std.sha256Hash(
      "478c9ca129fd2e3443fe27314b455e211e0d8c60bc8ff7df703873deeee580c2",
    ),
  })
  .unarchive("tar", "gzip")
  .peel();

…to this:

// New way, hash gets saved to the lockfile
const source = Brioche
  .download("https://github.com/jqlang/jq/releases/download/jq-1.7.1/jq-1.7.1.tar.gz")
  .unarchive("tar", "gzip")
  .peel();

…and the URL will automatically be downloaded and recorded in the lockfile! Note that this will require an update to the std package too, which is still in draft.

Registry updates

Right after release, @matklad opened a Zulip discussion to ask why installing hello_world took so long (and then also contributed brioche#54 to help stop the bleeding).

After a lot of back-and-forth with testing, I got some general fixes in place that went out with Brioche v0.1.1, but it still wasn’t a great experience. After a lot of investigation, @asheliahut and I ended up doing a major change to the registry.

To cut a long story short, the registry runs on ephemeral Fly.io machines, and I originally used LiteFS for the database (basically, SQLite with replication). LiteFS ended up causing a lot of latency and reliability issues, so we ended up migrating to a Postgres database hosted by Neon (which, so far, has been an amazing database host!)

Now, the registry should respond much faster, even when a Fly.io machine has to do a cold start!

Coming soon

To close this out, I wanted to share a shortlist of things currently in progress and things I’d like to make progress on in the near future! But… consider this more of a “wishlist” than a “roadmap”