Check out our GitHub!

cargo-dist

Releases

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

Version 0.21.0 (2024-08-13)

v0.21.0 Aug 14 2024 at 15:46 UTC

This release contains one major new feature and several bugfixes.

Improved glibc compatibility checking in installers

Our installers perform some preflight compatibility checks before installing in order to ensure that your binaries are compatible with the user's system. In particular, we check to ensure that the user's glibc is compatible with the version that your software linked against during its build.

In previous versions of cargo-dist, we hardcoded the version of glibc we expected your software to be built against based on the version used by our default Linux builders. Since the CI runners are configurable, however, it was possible for the actual glibc your package linked against to be different from the one we were expecting. This release adds new build environment tracking metadata, capturing information such as the system glibc/musl version your software linked against and the macOS version used to build. We use the real glibc information in your installers as of this release, and future versions of cargo-dist will make use of the other data we're now tracking.

Fixes

v0.20.0

v0.20.0 Aug 8 2024 at 17:51 UTC

This release contains several new features and bugfixes.

Support for packaging C libraries

Historically, cargo-dist has been focused on building and distributing binaries. There's so many more kinds of software out there, however, and we've had requests to package more kinds of artifacts. This release introduces support for two new kinds of build artifacts: C dynamic libraries, and C static libraries. While these would always be built in the past, we wouldn't package or install them for you. Starting with this release, we've now added the option to include these in your release tarballs/ZIPs and to install them in your installers.

We recognize that it may cause issues if existing binary-plus-library crates began unexpectedly installing libraries with this release, so we've introduced this feature as opt-in for the time being. It may be turned on by default in a future release. To enable packaging libraries in your tarballs/ZIPs, use the package-libraries configuration option. To enable installing libraries, use the install-libraries configuration option.

In the current release, libraries will be installed to the same locations as binaries in the shell and PowerShell installers, while the Homebrew installer will install them to the Homebrew-standard library paths. In the future, as we introduce new forms of installation layouts, we'll provide ways for the shell and PowerShell installers to install libraries to separate locations.

Rust users can produce these with the cdylib and staticlib crate types. For more information, see the Rust documentation. Generic build users can specify which libraries to include using the cdylibs and cstaticlibs configuration fields in dist.toml.

Custom pre-build actions in CI

This release introduces an experimental feature which makes it possible to run arbitrary extra build steps before cargo-dist's own build step during GitHub Actions runs. This can be useful for users who have mandatory pre-build setup they want to perform which can't be satisfied using the system dependencies feature. For example, a build which requires a custom installation of lua could specify that these two extra steps should be performed before the build begins:

- name: Install Lua
  uses: xpol/setup-lua@v1
  with:
    lua-version: "5.3"
- name: Check lua installation
  run: lua -e "print('hello world!')"

For more information, consult the documentation.

The First Rumblings Of 1.0

This release introduces the first steps in a major overhaul of cargo-dist that makes it more suitable for building and distributing apps that aren't written in Rust. This is something we've supported for a long time, but now we're making a big push to make it first-class and stabilizing all the parts.

There is also now experimental support for natively understanding JS projects, to make it easier to use dist for standalone JS executables. Read the new JS quickstart for details!

Several other pages of the docs have seen overhauls, and many more are to come.

Fixes