Workspace "profile ignored" warning discounts the possibility of publishing binary crates which use profile settings

[daboross]

Problem

When a profile section is provided in the Cargo.toml for a crate in a workspace that isn't the workspace root, the following warning is generated:

warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   /home/daboross/workspace/subcrate/Cargo.toml
workspace: /home/daboross/workspace/Cargo.toml

However, if subcrate is a binary crate published to crates.io, then the profile section will be used when someone cargo installs that crate. Moving the profile section to the workspace root would remove the settings when cargo installing the crate downloaded from crates.io.

Steps

1. Create a workspace & subcrate:

cargo new workspace && cd workspace && cargo new subcrate

2. Add workspace config:

echo "subcrate = { path = 'subcrate' }" >> Cargo.toml
echo "[workspace]" >> Cargo.toml

or copy whole Cargo.toml:

[package]
name = "workspace"
version = "0.1.0"
authors = ["David Ross <[email protected]>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
subcrate = { path = 'subcrate' }
[workspace]

3. Add profile to subcrate:

echo "[profile.release]" >> subcrate/Cargo.toml
echo "opt-level = 3" >> subcrate/Cargo.toml

Or copy whole Cargo.toml:

[package]
name = "subcrate"
version = "0.1.0"
authors = ["David Ross <[email protected]>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
[profile.release]
opt-level = 3

4. Build crates:

$ cargo build
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   /home/daboross/workspace/subcrate/Cargo.toml
workspace: /home/daboross/workspace/Cargo.toml
   Compiling workspace v0.1.0 (/home/daboross/workspace)
    Finished dev [unoptimized + debuginfo] target(s) in 0.36s

Possible Solution(s)

Add a way to ignore this warning, and output a suggestion for that when outputting the error? Could be something like

[cargo-warnings]
ignored-profile = "ignore"

And when the error occurs, something like:

note: this profile will be used when publishing binary crates. To ignore warning, add the following to /home/dabross/workspace/subcrate/Cargo.toml:
  [cargo-warnings]
  ignored-profile = "ignore"

Another option could be to provide an option to copy configuration from workspace root when publishing the crate?

Notes

Output of cargo version: cargo 1.45.0-nightly (258c89644 2020-04-30)

I found this bug from this post on the users.rust-lang.org forum. The user in question decided to simply not have a workspace to avoid this error, but I don't think that's a good solution in general.

[ehuss]

The team discussed this a bit. We feel like it would probably be best if cargo publish would copy the profile from the workspace into the member package. Does that sound like it would resolve your use case?

I have definitely felt uneasy with that warning, since it cannot be silenced. However, I'm also a little uncomfortable with adding config and machinery for silencing it (just to avoid complexity).

[kornelski]

I get the same warning, but I'm not publishing anything. Copying of the profile would not be useful to me.

I combine a few standalone projects into a large workspace using git submodules. In my setup that is easier to work with than Cargo git dependencies and [patch].

The problem is that one of the subprojects pulled into the workspace is usable independently, and has its own profile. That one subproject supports WASM, so it has a profile with panic=abort; opt-level = 's', but I don't want that setting for the whole workspace. I would prefer that subproject to keep its profile when it's used outside of my workspace, but keep the workspace overriding that with its own profile.

So to me Cargo does the right thing. I'm aware the other profile is ignored, and that's exactly what I want. I just don't need to be reminded about this on every build.

[ehuss]

An alternate solution we discussed would be to have some kind of nested workspace support for the git submodule use case. Cargo and Rust have the same problem, since they use git submodules. But it sounds like @kornelski specifically wants to disable the profile. Hmm..

[kornelski]

To me it'd make sense if Cargo had a similar allow/deny mechanism that rustc has.

My problem is also related to lack of per-target profiles: #4897. I wouldn't need the other profile to be ignored in the workspace context if I could limit that profile to WASM targets.

[jrvanwhy]

The team discussed this a bit. We feel like it would probably be best if cargo publish would copy the profile from the workspace into the member package. Does that sound like it would resolve your use case?

Hi, I'm the poster from users.rust-lang.org. Yes, that would resolve my use case.

[DzenanJupic]

I just ran into the issue @kornelski described. I have a workspace, and one of the crates is a WASM application which should be compiled with panic = "abort" and opt-level = 's'. By creating a [profile.release.package.<PACKAGE>] section in the workspace Cargo.toml I can set opt-level = 's'.

For panic = "abort" there seems to be a bug, since when I place it in the [profile.release.package.<PACKAGE>], cargo says:

error: failed to parse manifest at `PATH\TO\WORKSPACE\Cargo.toml`

Caused by:
  `panic` may not be specified in a `package` profile

And when I place it in the crates Cargo.toml cargo says:

warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   PATH\TO\WORKSPACE\PACKAGE\Cargo.toml
workspace: PATH\TO\WORKSPACE\Cargo.toml

So there's no way of setting panic = "abort" while making cargo happy.

[nickgerace]

I ran into this as well. Same as @DzenanJupic with panic = "abort".

[JesusGuzmanJr]

I also ran into the same issue as @DzenanJupic. I was able to sidestep the issue by removing the cargo workspace from my project and instead use workspace emulation as provided by cargo-make.

Before
So instead of using a cargo workspace with a virtual manifest like this:

# Cargo.toml
[workspace]
members = ["crate1", "crate2"]

After
I now use Makefiles in all my crates. This is what the root Makefile looks like:

# Makefile.toml
[env]
# this tells cargo-make that this directory acts as a workspace root
CARGO_MAKE_WORKSPACE_EMULATION = true

# a list of crate members. since we do not have a Cargo.toml, we will need to specify this in here.
CARGO_MAKE_CRATE_WORKSPACE_MEMBERS = [
  "crate1",
  "crate2",
]

After setting up Makefiles in all my other crates I can now build my project like so:

Debug Build
cargo make build

Release Build
cargo make build --profile production

With cargo-make's workspace emulation, I no longer get the "profile ignored" warning and my WASM is optimized in release builds. 🎉

[JoshMcguigan]

I have the same issue with wanting to specify panic = "abort" for one package in a workspace.

I noticed the cargo docs mention this limitation:

[profile.<name>.package.<name>]  # Override profile for a package.
# Same keys for a normal profile (minus `panic`, `lto`, and `rpath`).

Is there a fundamental reason cargo can't support this? Or is it more a matter of requiring some additional work to implement?

[EdmundsEcho]

Use case

In my use case I have what I believe is called a "virtual" workspace. Virtual because it does not hold any dependencies. I have 4 project members.

What is surprising, is that I get the warning when I call to compile one of the projects. For instance,

cargo build \
        --release \
        --target x86_64-unknown-linux-musl \
        --bin oauth \
        --target-dir target

Why give me a warning that the Cargo.toml in the project-member I'm trying to compile will be ignored? (which by definition of compiling, cannot be the case).

Impact ability to create a "dependency-only" layer when working in docker?

This all said, I do wonder if it somehow prevents my ability to create a "dependency-only" layer in my builds?... perhaps depending on whether I specify a specific member-project?

[WookashWackomy]

Any updates on this issue? It pollutes cargo build's output so much that it makes it hardly readable.
Right now I'm redirecting stdout/stderr to the file just to be able to read build log....I'm close to creating a custom filtering script just because I'm not able to follow/read build logs. Seems ridiculous :/

[epage]

What we do for the resolver field is we apply the workspace field to the individual packages when publishing so that the workspace's configuration is available for cargo install (#10911, #10961).

i would expect the same behavior for profile though it sounds like people are relying on this and it would be a breaking change. Maybe we could make this change on the next Edition.

[wackazong]

What about using the env var CARGO_PROFILE_<name>_PANIC as a workaround when building?

[lexspoon]

I get the same warning, but I'm not publishing anything. Copying of the profile would not be useful to me.

I combine a few standalone projects into a large workspace using git submodules. In my setup that is easier to work with than Cargo git dependencies and [patch].

The problem is that one of the subprojects pulled into the workspace is usable independently, and has its own profile. That one subproject supports WASM, so it has a profile with panic=abort; opt-level = 's', but I don't want that setting for the whole workspace. I would prefer that subproject to keep its profile when it's used outside of my workspace, but keep the workspace overriding that with its own profile.

So to me Cargo does the right thing. I'm aware the other profile is ignored, and that's exactly what I want. I just don't need to be reminded about this on every build.

My situation is close to this, and it seems like there's a problem to do with workspaces not supporting cross-compiling very well. Relatedly, it's a bummer having to use a separate wasm-pack command, and that may also be due to cross-compiling having some complications that the current workspace and cargo command do not do well with. Let me share what I see, with the caveat that I'm stumbling around and don't really know the limits of the current tools. I'm just following guides and trying to put together a reasonable work environment.

In my case, I'm also compiling to WASM, and I have all the modules pulled into the same VS Code session. It's just 3 crates, with about 2 more expected over the next year. I put them in the same Git repository and am not using sub-modules. In my case, it's a combination of WASM code, some proc macros that expand the WASM code, and eventually some server-side code that will run on Kubernetes. I jump around between all these modules constantly and so want them all to be loaded into VS Code. That's the scope of my Rust workspace right now from a conceptual point of view.

It seems like there are two root issues that could be helped by workspaces being a little smarter and knowledgeable about cross-compilation, which is a very realistic use case nowadays:

1. For workspaces to mach the scope of an IDE project, it's important that they are effective with having two different target architectures that the developer is working on. It happens quickly if you are cross-compiling to WASM or to a game console, because you sometimes compile to the native target even if the main thing you are doing is cross-compiling, e.g. for a macro definition. If you have multiple targets, though, then you likely want different Rustc options for each target architecture, but you're probably okay with using the same ones workspace-wide. Just because you optimized your WASM for size, though, doesn't mean you should have to optimize your macro expander with the same options, so there need to be two sets of options, one for each target platform.
2. The separate wasm-pack tool makes things quite awkward. I can't run cargo test and have it do the right thing for the project. I also can't use wasm-pack test in a non-WASM crate and get very far. So, wasm-pack is a wrapper of cargo but an incomplete one, which is the worst of both worlds. Things would work more smoothly if the wasm-pack magic could somehow be made into plugins for the cargo build and cargo test commands.