[Bug]: .cargo/config.toml is not deployed

[hseeberger]

What happened?

While working on an example app, I found out that .cargo/config.toml is not deployed. Yet this is needed to successfully compile, because the app is using uuid v7 which requires setting specific rustflags and that by default happens in .cargo/config.toml.

More details can be found at https://discord.com/channels/803236282088161321/1109452835214590123.

To reproduce the issue, use tag shuttle-issue-928: https://github.com/hseeberger/ticklist/releases/tag/shuttle-issue-928.

Version

0.16.0

Which operating systems are you seeing the problem on?

macOS

Which CPU architectures are you seeing the problem on?

ARM64

Relevant log output

No response

Duplicate declaration

• I have searched the issues and there are none like this.

[hseeberger]

According to @jonaro00, "hidden" files are not deployed. I suggest to modify the relevant logic to include "hidden" default files/directories like .cargo.

[hseeberger]

Looking at cargo_shuttle::make_archive, I think I disagree with @jonaro00: hidden(false) is called on the WalkBuilder, i.e. hidden files are not excluded by default.

As .cargo/config.toml is not in any .gitignore or .ignore files, I have no clue why the deploy fails.

[jonaro00]

Yeah, you're right. I misremembered.
What toolchain are you using locally?
This comment says that the rustcflags should be in a [target] field, and the string should also be split into two. https://www.reddit.com/r/rust/comments/yindaf/comment/iujnbgo/
Perhaps it is an issue with mismatching environments locally/in deployment.

[jonaro00]

This sparked an idea: #930

[imor]

I tried locally and in my case at least the .cargo/config.toml file was included in the archive. So it looks like it may not be due to the file missing from the archive. @hseeberger Do you have the project you were deploying available on Github? I can try deploying it as well.

[hseeberger]

@jonaro00, using macOS on M1 (ARM64) as given in the description. The .cargo/config.toml looks like this and works fine locally:

[build]
rustflags = "--cfg uuid_unstable"

@imor, the link and tag to the project are given above: https://github.com/hseeberger/ticklist/releases/tag/shuttle-issue-928. Make sure to use the tag shuttle-issue-928, because I have switched to a v4 Uuid to work around this issue.

[imor]

Sorry @hseeberger missed the link in the description. I also ran into the same problem. The project builds locally for me but when deployed it fails because of missing Uuid::now_v7(). It has something to do with how shuttle builds the project.

[jonaro00]

Are you both using Rust 1.69? Deployment uses 1.68. I didn't see anything related to this but it is after all a source of errors, so just double checking.

[imor]

Yes, I'm on 1.69.

[hseeberger]

@jonaro00, I was on 1.69, but I installed 1.68(.2) and the behavior is exactly the same, i.e. cargo shuttle run works but cargo shuttle deploy fails.

[imor]

I setup a dev environment of shuttle locally and was able to capture the rustc command run by the deployer. I also extracted the rustc command when I built this project manually from the command line. Here they are:

From deployer:

rustc --crate-name ticklist --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C opt-level=3 -C embed-bitcode=no -C metadata=befa05399f0bfb08 -C extra-filename=-befa05399f0bfb08 --out-dir /opt/shuttle/shuttle-builds/ticklist/target/release/deps -L dependency=/opt/shuttle/shuttle-builds/ticklist/target/release/deps --extern anyhow=/opt/shuttle/shuttle-builds/ticklist/target/release/deps/libanyhow-1638cbbc81c3f7f3.rlib --extern axum=/opt/shuttle/shuttle-builds/ticklist/target/release/deps/libaxum-2ba8f8a7929d7a3b.rlib --extern paste=/opt/shuttle/shuttle-builds/ticklist/target/release/deps/libpaste-f1c151bbee1ee7c1.so --extern serde=/opt/shuttle/shuttle-builds/ticklist/target/release/deps/libserde-b3c9a0db670b0ea6.rlib --extern serde_json=/opt/shuttle/shuttle-builds/ticklist/target/release/deps/libserde_json-20582b8a1e30c74c.rlib --extern shuttle_axum=/opt/shuttle/shuttle-builds/ticklist/target/release/deps/libshuttle_axum-1d72117bc32347b9.rlib --extern shuttle_runtime=/opt/shuttle/shuttle-builds/ticklist/target/release/deps/libshuttle_runtime-c6e9a41d76cdf834.rlib --extern shuttle_shared_db=/opt/shuttle/shuttle-builds/ticklist/target/release/deps/libshuttle_shared_db-03ffa76c6dbdce21.rlib --extern sqlx=/opt/shuttle/shuttle-builds/ticklist/target/release/deps/libsqlx-36d9f86f38b99fed.rlib --extern time=/opt/shuttle/shuttle-builds/ticklist/target/release/deps/libtime-11b310034dddb839.rlib --extern tokio=/opt/shuttle/shuttle-builds/ticklist/target/release/deps/libtokio-09e9586ca212729e.rlib --extern tracing=/opt/shuttle/shuttle-builds/ticklist/target/release/deps/libtracing-eb7198a2f9321a15.rlib --extern uuid=/opt/shuttle/shuttle-builds/ticklist/target/release/deps/libuuid-c29b2407f470ea3a.rlib -L native=/opt/shuttle/shuttle-builds/ticklist/target/release/build/ring-6ed57d11f423598d/out

When built locally:

rustc --crate-name ticklist --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=236 --crate-type bin --emit=dep-info,link -C opt-level=3 -C embed-bitcode=no -C metadata=c048a64ab8897d86 -C extra-filename=-c048a64ab8897d86 --out-dir /home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps -L dependency=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps --extern anyhow=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps/libanyhow-5df34bb51d9247ce.rlib --extern axum=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps/libaxum-3bd3c50febe49d2f.rlib --extern paste=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps/libpaste-bd3fcb0ba9ea8555.so --extern serde=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps/libserde-bd5b8be1da3d0c90.rlib --extern serde_json=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps/libserde_json-1ccde61105a905b3.rlib --extern shuttle_axum=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps/libshuttle_axum-353819e5ca3e714e.rlib --extern shuttle_runtime=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps/libshuttle_runtime-c32c783574a846e4.rlib --extern shuttle_shared_db=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps/libshuttle_shared_db-f1c0bf27471d55d3.rlib --extern sqlx=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps/libsqlx-8be9b4f7a0799602.rlib --extern time=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps/libtime-dfa94cfa1b8a0beb.rlib --extern tokio=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps/libtokio-fe4f75ef640e22de.rlib --extern tracing=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps/libtracing-db764db6906d276c.rlib --extern uuid=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/deps/libuuid-26fdc592e76f2dc5.rlib --cfg uuid_unstable -L native=/home/romi/src/rust/shuttle/examples/rocket/ticklist/target/release/build/ring-de41e7b0d5ffe2b9/out

(Sorry for the long horizontal scroll)

The only significant difference between them is the --cfg uuid_unstable option which is missing from the deployer's command line which I believe is the root cause of compilation failure. Now need to find out why did deployer not pass this option.

[hseeberger]

Hey @imor, thanks a lot for investigating! I am currently also trying to set up a local dev environment, but as I am a Shuttle newbie, this is taking some time ;-)

Yes, --cfg uuid_unstable is essential for my project to build. Is the deployer not using "standard Cargo"? Sorry if this question sounds stupid, I yet don't know how it is working. Because if you run cargo check (or cargo build or ..) the options under .cargo/config.toml are always considered.

Hence I assume that the deployer does not use cargo, but instead tries to do the same thing. If that is the case, then considering the cargo configuration options seems to be missing.

[jonaro00]

The deployer uses the same function in the builder crate as local run, and it uses cargo (as a lib) internally (it will soon use the hosts installed cargo instead).
I suspect the issue could be about either working directories, or if the .cargo/config.toml file already exists in the container and gets ignored when unpacking.

[aumetra]

Shuttle uses a "global" Cargo configuration (i.e. $CARGO_HOME/config.toml) to patch the shuttle-* crates and to register their crates.io mirrors. This global config takes precedence over the per-project configuration (because Cargo doesn't to configuration merging; pretty annoying). Not sure if the local run does that, too?

I ran into pretty much the same issue and ended up forking the uuid crate and patching it in.

[aumetra]

It would be interesting though if there was a RUSTFLAGS field (or similar) in the Shuttle.toml, where one could pass such things.
Back when I hit this issue, there was still the FFI boundary Shuttle had to worry about, and certain cfg flags could potentially break FFI compatibility (something like tokio_unstable when combined with tracing, where it would embed spans into the structs).

With the boundary gone, Shuttle should be much more flexible and introducing something like that should cause little-to-no problems IMO

[oddgrd]

It would be interesting though if there was a RUSTFLAGS field (or similar) in the Shuttle.toml, where one could pass such things. Back when I hit this issue, there was still the FFI boundary Shuttle had to worry about, and certain cfg flags could potentially break FFI compatibility (something like tokio_unstable when combined with tracing, where it would embed spans into the structs).

With the boundary gone, Shuttle should be much more flexible and introducing something like that should cause little-to-no problems IMO

Thank you for the great summary! Yes, I also think this should be possible to implement now. I like the suggestion of using Shuttle.toml for this, then we just need to sort out how we will write them to the cargo config (or even passing them as args when building the project binary?).

[jonaro00]

What if the global cargo config in Shuttle was instead injected into any existing user's cargo config (or created if not present)?

[jonaro00]

@hseeberger This should be possible in 0.27 🤞, haven't verified.