Check out our GitHub!

cargo-dist

Releases

Version 0.5.0 (2023-11-27)

v0.5.0 Nov 27 2023 at 18:37 UTC

This release was probably going to be several releases, but everything got finished at the same time, so here's a Mega Release!

The headline features are:

  • New Support For Axo Releases, As An Alternative To Github Releases (Launching Soon™)
  • New Support For Generic Build Steps, In Any Language (Experimental)
  • Significantly Improved MSI Installer Support

Features

Axo Releases

Axo Releases users can now enable builtin cargo-dist support by setting

hosting = ["axodotdev"]

in their [workspace.metadata.dist].

To sign up for the Axo Releases closed beta, go to https://dash.axo.dev/

You can ask for more details by joining our discord or sending a message to [email protected]!

Axo Releases has a more robust pipelined model for creating and hosting a release, which more closely matches the actual design of cargo-dist. But since we'd only ever supported Github Releases, some significant internal reckoning was required.

This reckoning primarily appears in the existence of the new "cargo dist host" subcommand, which was created to make "side-effectful networking" explicit, instead of riddling several random commands with various --dry-run flags.

host takes several --steps:

  • create: ask Axo Releases to create hosting for the Apps we want to publish
  • upload: upload built Artifacts to the hosting that create made
  • release: create Releases for the hosted artifacts, making perma-urls like /v1.0.0/ live
  • announce: announce all the Releases, wiring them into "list all releases" and "latest release" endpoints
  • check: equivalent to create but just checks that authentication is properly setup, without side-effects

The distinction between upload, release, and announce in particular lets us provide a more reliable/transactional release process -- we can make the hosting live, publish to package managers, and then update URLs like /latest/ once everything works, instead of racily doing it all at once and having to frantically hack things back to normal when something weird happens. It should also make it possible for us to provide features like Release/PR Previews.

Generic Builds

0.5.0 contains experimental support for building non-cargo-based projects. These can be in any language, and follow any repository layout, so long as they're accompanied by a cargo-dist manifest file that provides information on how to build and install it. For more information, consult the documentation.

MSI

We've contributed several upstream improvements to cargo-wix, the tool we use to build MSIs, and integrated that functionality back into cargo-dist.

Where previously you needed to use cargo-wix CLI flags to set various images in your installers, they are now exposed in [package.metadata.wix] as well as banner, dialog, and product-icon.

There are now also eula and license configs on [package.metadata.wix] that allow you to specify where to source the eula/license from, and also allow you to explicitly disable auto-eula/auto-license functionality with eula = false and license = false. cargo dist init will by default set those to false if it sees they aren't defined in [package.metadata.wix] yet, making things more well-behaved by default. To restore the old auto-eula behaviour, set them to true.

In addition, significant refactoring was done to the eula/license backend of cargo-wix so that cargo-dist can properly understand when those files need to be auto-generated. Previously auto-generated licenses/eulas would just produce broken templates, because cargo-dist wouldn't know about them and get confused.

Source Tarballs

cargo-dist will now generate its own source tarballs, and upload them to your release, named "source.tar.gz". The source tarballs that github provides are actually generated on demand with unspecified settings, so to ensure both Axo Releases and Github Releases have access to the same results, we need cargo-dist to generate the source tarball itself. We use the same mechanism as Github (asking git itself to generate them), but we can't bitwise-identically reproduce their (unspecified, technically-not-guaranteed) behaviour.

Maintenance/Fixes

Version 0.4.3 (2023-11-08)

v0.4.3 Nov 8 2023 at 22:43 UTC

This is a small bugfix release which resolves an issue where we would sometimes generate non-working Homebrew installers.

Version 0.4.2 (2023-10-31)

v0.4.2 Oct 31 2023 at 13:50 UTC

Just a little release to get a couple small fixes in people's hands!

(This is a rerelease of 0.4.1, because that one wasn't properly rebased to include all the advertised fixes.)

Version 0.4.1 (2023-10-30)

v0.4.1 Oct 30 2023 at 22:20 UTC

(See 0.4.2 for the actual release)

Just a little release to get a couple small fixes in people's hands!

Version 0.4.0 (2023-10-25)

v0.4.0 Oct 25 2023 at 15:29 UTC

This release contains several major features related to package dependencies. cargo-dist can now install dependencies for you in CI, ensure your users have those dependencies in their installers, and provide you insights into what external libraries your package links against! It also enables support for statically-built musl binaries on Linux.

Features

Install custom dependencies

Way back in our very first blog post, we wrote about how users could customize the GitHub CI scripts we output to install custom dependencies. As of cargo-dist 0.4.0, you won't need to do that anymore! System dependencies — that is, dependencies installed via the system's package manager instead of cargo — can now be specified in your cargo-dist config in Cargo.toml using a syntax very similar to how your cargo dependencies are specified. For example:

[workspace.metadata.dist.dependencies.homebrew]
cmake = { targets = ["x86_64-apple-darwin"] }
libcue = "2.2.1"

[workspace.metadata.dist.dependencies.apt]
cmake = '*'
libcue-dev = { version = "2.2.1-2" }

For more information, see the documentation.

Find out what your builds linked against

Complementing the ability to specify system dependencies, we've added a new feature that lets you tell which libraries your Rust programs have dynamically linked against. While most Rust software is statically linked, installing external dependencies may mean that your software links against something on the system; you can visualize which libraries your software uses, and which packages they come from, by viewing the output of the build step in CI.

In addition, cargo-dist now uses this information to choose which dependencies to specify when building system package manager installers such as a Homebrew formula. If cargo-dist detects that your binary links against a package provided by Homebrew, it will ensure that a user who brew installs your package will also get that other package.

This feature has full support for macOS and Linux. On Windows, we're not able to list which package a system library comes.

musl support

This release adds support for a long-requested feature, creating Linux binaries statically linked against musl instead of glibc. These can be enabled adding the x86_64-unknown-linux-musl target triple to your list of desired targets.

Note that because these binaries are statically linked, they cannot dynamically link against any other C libraries — including C libraries installed using the system dependency feature mentioned above. If your software links against system libraries, please ensure that a static library is available to the build.

msvc-crt-static opt-out

cargo-dist has always forced +crt-static on, as it is considered more correct for targetting Windows with the typical statically linked Rust binary. However with the introduction of initial support for chocolatey as a system package manager, it's now very easy for our users to dynamically link other DLLs. Once you do, it once again becomes more correct to dynamically link the windows crt, and to use systems like Visual C(++) Redistributables.

Although we would like to teach cargo-dist to handle redistributables for you, we're starting with a simple escape hatch: if you set msvc-crt-static = false in [workspace.metadata.dist], we'll revert to the typical Rust behaviour of dynamically linking the CRT.

Version 0.3.1 (2023-09-28)

v0.3.1 Sep 28 2023 at 21:35 UTC

This is a minor bugfix release which fixes an issue certain builds would encounter on Windows.

Fixes

Windows builds run under Powershell

Starting in version 0.3.0, we switched Windows builds to run under bash instead of Powershell. This introduced problems for certain builds, so we've switched them back to Powershell.

The majority of users will not be affected by this and will not need to upgrade; this primarily affects a limited number of users building software with libraries or dependencies which are sensitive to the shell in which they're built. For example, users building OpenSSL on Windows as a part of their cargo-dist build may have been affected.

  • @frol + @mistydemeo impl

Version 0.3.0 (2023-09-27)

v0.3.0 Sep 27 2023 at 14:50 UTC

This release is a big overhaul of cargo-dist's UX! Our CI scripts have been completely redesigned to allow your release process to be tested in pull-requests, so you don't have to worry as much about your release process breaking!

Since we can now test your release process frequently, we've also made most cargo-dist commands default to erroring out if anything is out of sync and needs to be regenerated.

To make this easier, we've also introduced an experimental new system for user-defined hooks, allowing you to write custom publish jobs without having to actually edit release.yml.

This release also introduces initial support for msi installers with the wonderful help of cargo-wix!

Features

CI redesign

This is the big ticket item of the release, the CI has been completely redesigned! We recommend reading the docs below for details, but some high-level details:

  • The CI now runs cargo dist plan on pull-requests

  • This can be cranked up to cargo dist build, with results uploaded to the PR workflow, allowing you to download+test them

  • To do this, we now use GitHub's upload-artifact/download-artifact system, instead of using a draft GitHub release as scratch storage

  • This means we also no longer create a draft Release on startup, and instead transactionally create the full Release at the very end

  • cargo dist plan will now check that the CI script is up to date and not hand-edited (can be opted out)

    • The user-defined publish jobs feature helps you avoid hand-edits
    • More such features are in the pipeline for the next release!

  • impl

  • docs

user-defined publish jobs

You can now define custom hand-written publish jobs that cargo-dist's CI will know how to invoke, without actually having to hand-edit release.yml!

default to not publishing prereleases to homebrew

Homebrew doesn't have a notion of package "versions", there is Only The Latest Version, so we changed the default to only publishing to your homebrew tap if you're cutting a stable release. You can opt back in to the old behaviour with publish-prereleases = true.

generate command

This feature is a bit of an internal affair that you don't necessarily need to care about, but it's big enough that we figured it's worth mentioning.

The "plumbing" generate-ci command which is invoked by cargo dist init has been reworked into a more general generate command, as the introduction of msi installers means we now have two kinds of checked-in generated output.

Most notably, generate --check now exists, which produces an error if generate would change the contents (ignoring newline-style). Most cargo-dist commands now run generate --check on startup, making it an error to have your release.yml out of date or hand-edited. This is a key piece to the puzzle of the new CI design, as it lets you catch issues with your release process in PRs.

The allow-dirty = ["ci"] config was introduced to disable these generate modifying or checking release.yml, for users that still really need to hand-edit. We're actively working on several features that should make it less necessary to do hand-edits.

msi installer

Initial msi installer support is here, based on the wonderful cargo-wix. We contributed several upstream improvements to cargo-wix for our purposes, and look forward to helping out even more in the future!

Fixes

more useful checksum files

The checksum files we generate are now in the expected format for tools like sha256sum, making them more immediately useful.

Maintenance

more polished cli output

CLI Output has been streamlined and cleaned up a lot in this release!

refreshed docs

The docs have been significantly reworked to reflect how much cargo-dist has changed and improved over the last few releases. Installers have rapidly grown from "something we're trying out" to "the star of the show", so they're now front-and-center with room for their own guides.

This was a big undertaking, and not everything has been reworked yet. Further improvements will be done more incrementally.