axodotdev / cargo-dist

📦 shippable application packaging
https://axodotdev.github.io/cargo-dist/
Apache License 2.0
1.55k stars 73 forks source link

Feature: specify system packages #423

Closed mistydemeo closed 12 months ago

mistydemeo commented 1 year ago

Right now, users can specify cargo dependencies for their package via Cargo.toml, but we don't provide a way for users to specify system packages that need to be present during the build. We should provide a way for developers to specify system packages that will be present on the builders during their build.

My current plan is to add a new system-dependencies key to Cargo.toml. This allows the user to specify the dependencies per package manager. When we run a build on a system that uses that package manager, we install those dependencies prior to running the build. It looks something like this:

system-dependencies = { apt = ["libcue-dev"], homebrew = ["libcue"] }

Some of these dependencies will end up being required at runtime for users of the software, but not all of them. Some of these dependencies will be build tools such as cmake, which are totally unnecessary once the software is built, while others will be libraries that will be dynamically linked against and required by the resulting binary. We should leverage #422 to determine which packages are actually needed at runtime, and inject those packages as dependencies of our package manager manifests such as the Homebrew formula.

For Homebrew builds, I plan to use Brewfiles and brew bundle exec. This will allow us to ensure that the build is able to find Homebrew-provided dependencies even if they end up outside cargo's default search paths with the least fuss.

FreeMasen commented 1 year ago

With #428 merged, is this now available? The mdbook states that workspace.metadata.dist.dependencies.<pkg-mgr>.<dep> should work, is that the case today?

I ask because I am looking to add a step like this in a CI job but adding these keys and running cargo dist genrate doesn't seem to update .github/workflows/release.yml

mistydemeo commented 1 year ago

We haven't yet released 0.4.0, which is the release that will include this feature. While we may have a prerelease out before then, it'll be a little longer until it's included in a stable release.

FreeMasen commented 1 year ago

Thank you for the reply. I didn't realize that the since <version> header could include not-yet released versions and didn't look closely enough. Sorry for the extra noise here.

xoolive commented 8 months ago

Hi @mistydemeo

May I ask what is the recommended way of proceeding when dependencies are not packaged?

In my situation, I have proper system dependencies for Linux and MacOS with apt/brew (working fine!). For Windows, I have a few lines to run before building my executables (nothing on choco).

I found the "reusable workflow" item in the documentation, but it is not clear to me whether what I would install with such a workflow would persist in the runners of the build artifact matrix later?

Not sure where to ask, but this issue seems related... Have a nice week-end