dist seems to ignore environmnet variables configured in .cargo/config.toml

[jan-ferdinand]

tl;dr: minimally failing example

Description

In a project I'm working on, we're using tokio's unstable features. Those features require opt-in through an environmnent variable. This environment variable can be set in the file .cargo/config.toml, which is what we do. Unfortunately, dist build seems to ignore this configuration. As a result, the compilation step during dist build fails.

What I've tried

• Running RUSTFLAGS="--cfg tokio_unstable" dist build¹ works fine.
• I cannot find anything applicable to this situation in the dist book.
• I was unable to identify similar issues here on github.

Questions

1. Do you consider this a bug or missing feature, or am I miss- or even abusing dist?
2. Is there a maintainable workaround? I feel uncomfortable monkey-patching the release.yml to jam this environment variable in there every time I run dist init.
3. Do you need or want any additional information?

Footnotes

1. as you might expect, RUSTFLAGS="--cfg tokio_unstable" is the environment variable configured in .cargo/config.toml ↩

[ashleygwilliams]

hello @jan-ferdinand ! thank you so much for the detailed issue and repro, it's super appreciated. offhand, this feels like a bug to me as i know we have code to handle RUSTFLAGS (https://github.com/axodotdev/cargo-dist/blob/main/cargo-dist/src/build/cargo.rs#L73).

i agree that editing the release.yml file is very undesirable. if in the meantime you need to, we do offer the allow-dirty flag but, this is something to use as a last resort.

you may be able to use the custom-build-step feature to work around this for now, though i think we'd want to fix this as i think it's a bug.

out of curiousity- is the project you are building part of a workspace? by default, we run cargo build --workspace and i wonder if maybe that is why the cargo config is getting dropped? we have a feature called precise-builds that you can use to change that build command to build each package individually (this has some potentially negative edge case side effects, but it would be a good experiment).

[jan-ferdinand]

Thanks for your speedy reply & help!

offhand, this feels like a bug to me as i know we have code to handle RUSTFLAGS

The FIXME: comment does indeed suggest that dealing with RUSTFLAGS is both complex and not yet complete. Perhaps a library like cargo-config2 could help? I have no experience with it, but its description and the example in the readme sound like it could be a good fit.

you may be able to use the custom-build-step feature to work around this for now

Thanks for the pointer. I will play around and see if I can get something going.

is the project you are building part of a workspace?

The project where I stumbled across this is a workspace, yes. The minimal failing example repository is not. This seems to suggest that workspaces have nothing to do with it, but this is not a very educated guess. Of course, different bugs could cause seemingly identical behavior.

[jan-ferdinand]

I have managed to work around the concrete issue using a custom build step feature, as thankfully suggested by @ashleygwilliams. Should somebody else stumble across this issue between now and a fix for the underlying bug, here are some gottchas I ran into:¹

• The custom build step workflow file cannot be syntactical. Using the default name introduces an always-failing workflow run. Dropping the file extension .yml makes github ignore the workflow, but allows dist to still pick it up.
• The location for the github-build-setup key is correctly documented here, but incorrectly documented here.
• Things break if too many (nested & escaped) quotation marks are present in the custom build step.

# this works
  run: echo RUSTFLAGS="$RUSTFLAGS --cfg tokio_unstable" >> "$GITHUB_ENV"
# this does not work
  run: echo "RUSTFLAGS=\"$RUSTFLAGS --cfg tokio_unstable\"" >> "$GITHUB_ENV"

The version that doesn't work is closer to the documented way of setting an environment variable in a github workflow.

Footnotes

1. Of course, the custom build step feature is documented as experimental. ↩

[ashleygwilliams]

Hey @jan-ferdinand !

First off, really glad the custom build step worked for you. I very much appreciate the detailed experiment report as well. If you are interested in making a PR to fix the docs, let me know, otherwise I'll make sure that gets handled. I think if you were interested in adding any of the caveats you've mentioned here to the docs, that would be great as well.

You are right about the comment noting the difficulty of RUSTFLAGS- I'll take a look at the crate you mentioned and see if we can get you off the custom build step soon. If you are interested in taking it on I would be happy to help you through it!