cargo-dist

Releases

Version 0.25.1 (2024-11-01)

v0.25.1 Nov 1 2024 at 18:47 UTC

This release contains a few new features for further customizing the installer experience, both as a packager and the end user.

Artifact location installer customization

We now provide two new environment variables making it possible to customize just the base URL for fetching installers. Previously, the only customization for overriding the install URL overrode the full URL, including version-specific paths, which made it difficult to use for users who were proxying or mirroring GitHub paths. These new variables are branded with your app's name. For example:

  • {app_name}_INSTALLER_GITHUB_BASE_URL
  • {app_name}_INSTALLER_GHE_BASE_URL

These two variables will also be supported by a new version of axoupdater in order to allow overriding the GitHub API URL. Thank you to user @gaborbernat for inspiring this change and writing the axoupdater side!

  • impl @mistydemeo [feat: allow installer domain to be overridden](feat: allow installer domain to be overridden)

You can learn more about this feature in the artifact location installer usage documentation.

Default glibc version override

Ordinarily, dist automatically detects the version of glibc used by your linux-gnu builds and uses this in the installers to detect if the end user's system will be compatible. In certain specific build environments, this autodetection isn't possible, so we've introduced a feature allowing the glibc version to be manually specified in the dist configuration. If provided, this replaces the fallback version that would otherwise be used.

Version 0.24.1 (2024-10-29)

v0.24.1 Oct 29 2024 at 18:22 UTC

Loosens the "cargo is broken" error reporting condition, letting us be more precise about cases where Cargo is present but Cargo metadata can't be parsed.

Version 0.24.0 (2024-10-28)

v0.24.0 Oct 28 2024 at 17:23 UTC

It's been less than two weeks, and we're already back with a big dist release for you. This release has several major features, beginning with the biggest news that:

dist has a new name

Did the last paragraph give it away? Well, it's true: cargo-dist is now just dist. This reflects our growing support for packaging software built by tools beyond just Cargo. Our support for Cargo isn't going away of course, or becoming any less of a focus.

As a part of this, dist has moved towards a standalone CLI tool that doesn't have to be run as a cargo subcommand. You can now run dist init, dist build and more without needing to prefix it with cargo. We still install the Cargo plugin, though, so you're welcome to keep using cargo dist like always. As a part of being able to run without the Cargo plugin, there's one more big change:

dist runs without Cargo

dist no longer requires Cargo if you're not building Rust projects! This is a major change which should make it much more ergonomic for users of other languages. We do still require Cargo if your workspace contains at least one Rust project; this includes commands such as dist init and dist plan.

Unified checksum file

This change is completely unrelated to the new name, but it's a very nice one. We've always shipped individual checksum files for each artifact, but in this release we now also ship a unified checksum file which contains all of your hashes in a single place. It's named $HASH_STYLE.sum, for example sha256.sum, and is designed to be compatible with tools such as shasum and sha256sum.

Fixes

Version 0.23.0 (2024-10-15)

v0.23.0 Oct 15 2024 at 20:40 UTC

We're back from a longer-than-usual break between releases with a feature-filled release!

The new config format emerges

Over the past few months, we've been working towards a new config format. Up to now, aside from a few references in the documentation, these changes have been internal and haven't been visible to users. This release marks the first user-facing side of the new config format.

This new config format uses the dist-workspace.toml and dist.toml files that were originally created for non-Rust projects. It allows us to unify project configuration formats between languages, and allows you to configure cargo-dist without adding content to your root Cargo.toml. In this release, newly cargo initted Rust projects will use the new format. Existing projects will be given the option to opt into the new format, but by default will keep their existing format for now.

For more information, see the workspace docs.

Installer improvements

This release contains a suite of improvements to our installers.

"Unmanaged" install type

We now support a new install type, "unmanaged" installs. This is intended for users installing in ephemeral install methods such as CI, and disables several features that are unneeded in those environments. Specifically, it:

  • Disables updater-related tooling, including install receipt creation
  • Disables modification of the user's PATH, including modification of dotfiles
  • Forces a flat installation layout, installing all files into a single directory

For more information, see the installer usage docs.

Improved path modification options

While we've always provided options to turn off modifying the user's PATH in the installer, this behaviour was inconsistent between the shell and PowerShell installers. In this release, we've unified the behaviour. The current recommended path is to use environment variables; the variable controlling this is APPNAME_NO_MODIFY_PATH, where APPNAME is the name of your application. For example, AXOLOTLSAY_NO_MODIFY_PATH for an app named axolotlsay. The commandline flag, which was named inconsistently between platforms, has been deprecated.

We've also made a change to ensure that the user's preference for the "don't modify PATH" option is persisted across upgrades. This fixes an issue present in previous versions where it would only be respected on initial installation, not in calls to axoupdater.

For more information, see the installer usage docs.

npm packages can now use any archive format

In previous versions, enabling the npm installer would require your package to be distributed using .tar.gz archives on all platforms, including Windows. This release removes that restriction by rewriting a section of the npm installer code.

Axoupdater version checking

Users who implement an updater by using axoupdater as a library always need to make sure that library is up to date so that they're able to make use of the latest features. This release contains a version checker which detects if your software is using an out-of-date version of axoupdater which may cause problems, and will alert you that an update is needed during builds. For more information, see the documentation.

Standalone axoupdater installation fix

cargo-dist versions 0.21.1, 0.22.0 and 0.22.1 contain a bug which caused the standalone installer to fail to install when using the shell installer. End users who installed your software via installers generated with these versions will not have received a standalone installer along with your software. This bug is fixed beginning with this release. For more information, see the documentation.

Version 0.22.1 (2024-09-04)

v0.22.1 Sep 5 2024 at 00:05 UTC

This is a small patch release that incidentally includes some initial groundwork for a new feature.

Version 0.22.0 (2024-08-28)

v0.22.0 Aug 29 2024 at 00:21 UTC

This patch release fixes several bugs and provides some nice quality of life improvements. These fixes are largely related to our installers, shell, powershell, and homebrew as well as managing some papercuts in the dist init command and error handling.

App-branded installer environment variables

We generate installers for our users- and then our users' users use those installers. Those users don't know they are using dist and, if we do our job right, should never have to.

While we had implemented some environment variables that enable users to control the behavior of installers, previously they were largely designed for internal use, and therefore namespaced with DIST. However, we quickly realized that this isn't suitable for having our users communicate with their users- so we've enabled the generation of app-branded installer customization environment variables- so that installer users can leverage environment variables that are branded to the application they are trying to install.

Right now, the only customization we allow for installers is the install directory- so instead of CARGO_DIST_FORCE_INSTALL_DIR, you can tell your users to use AXOLOTLSAY_INSTALL_DIR (if your app is named axolotlsay). If you have a name with hyphens or other characters, we normalize it for you, and you can find this value at the install_dir_env_var field in the dist-manifest.json that is generated with each of your releases.

Homebrew license metadata

Currently, when publishing to a Homebrew tap, whatever string is in the project's license field (usually a SPDX license expression) gets passed into license in the Homebrew formula. However, rather than using SPDX syntax, Homebrew has its own ruby syntax for specifying licenses. So, when passed an SPDX expression, Homebrew:

  • Cannot provide as detailed information about the package's licensing.
  • Throws errors when linting the formula with brew audit/brew test-bot.

This PR translates the SPDX expression to the Homebrew license DSL.

Homebrew compliance (brew style)

Creating a personal tap with brew tap-new creates a default Github Actions workflow that runs a homebrew-specific style check (brew style ) on the repo. Cargo-dist's generated homebrew formulas fail this style check. This does not block the core functionality of cargo-dist's homebrew publishing functionality (formula still functions), but does mean that users whorun brew style (which is a side effect of creating a tap with brew tap-new) would get frustrating errors.

Rather than separately chasing formatting issues as they come up, this PR updates the homebrew publish workflow to install and run brew style --fix on each formula before committing it.

Fixes

Version 0.21.1 (2024-08-20)

v0.21.1 Aug 20 2024 at 17:35 UTC

This patch release fixes several bugs and provides some quality of life improvements. The most substantial changes are to the shell installer, which now does more precise glibc version checks based on exactly which platform each binary was built on.