How to reason through Cargo workspace?

[j-baker]

Hi! I've got a Cargo workspace which has two binaries in them, cli and server, as well as a few other crates. Reading the docs, it's not quite clear to me how I should go about configuring this with Crane. At present, I've solved by having two build tasks, like

    cli = craneLib.buildPackage (commonArgs // {
        inherit cargoArtifacts;
        pname = "helcache";
    });
    server = craneLib.buildPackage (commonArgs // {
        inherit cargoArtifacts;
        pname = "server";
    });

but this still pumps out warnings like

trace: warning: crane will use a placeholder value since `name` cannot be found in /nix/store/gjid9c55li2p761pkvq30nbksb7ckpr2-Cargo.toml
to silence this warning consider one of the following:
- setting `pname = "...";` in the derivation arguments explicitly
- setting `package.name = "..."` or `workspace.package.name = "..."` in the root Cargo.toml
- explicitly looking up the values from a different Cargo.toml via 
  `craneLib.crateNameFromCargoToml { cargoToml = ./path/to/Cargo.toml; }`

and each package appears to contain both binaries. This is all to say - how do you envisage people use workspaces?

[dpc]

AFAIR pname is only for the name of the resulting Nix derivation, so your two derivations are exactly the same, just with a different name.

craneLib.buildPackage is a bit confusingly named because what it really comes down to is "call cargo build, take all the binaries and make them the result of the derivation".

We have a complex (> 10 binaries, > 20 crates) setup with crane and there's a lot of nuance there w.r.t. the fact that building only a subset of crates (with cargo build -p <crate>) potentially changes the dependency selection.

But my solution is to: build groups of packages (or whole workspace), and then create new derivations that just "pick a given binary":

https://github.com/fedimint/fedimint/blob/4919189a5990335ce9ae8583b0a9b741b42aaf17/flake.nix#L122

[j-baker]

Ok - that makes sense. So way you do it is grab the whole output and extract the bits you need. How were you able to get rid of the warning? We get it about 5 times per build.

[dpc]

Seems like pname should do the trick. Maybe it's a bug? I think there were a handful of existing issues about it.

[ipetkov]

@j-baker how is cargoArtifacts instantiated and does it set pname explicitly?

My hunch is if the root of the project is a [workspace] definition (which does not set a package.name or workspace.package.name) there is no name to be inferred

[j-baker]

Right now, what I have is something like:

commonArgs = {
    pname = "myname";
    ...
};

cargoArtifacts = craneLib.buildDepsOnly commonArgs;

somethingElse = craneLib.buildPackage (commonArgs // {
    inherit cargoArtifacts;
});
// cargo clippy etc - it's basically the flake template

and running nix flake check I get out oodles of these warnings.

[ipetkov]

@j-baker is there a(n ideally minimal) flake that I can use to reproduce the issue?

[iwinux]

Here's a minimal example that DOES NOT have any warnings: https://github.com/iwinux/crane-test.git

Initially it did emit warnings about pname (see https://github.com/iwinux/crane-test/blob/626937d5aa79e00bb0c31b3cc43e83f7a610a116/flake.nix), but that was because I didn't wrap common // { pname = "..."; } with ().

[j-baker]

I think this was my problem, as you are all indicating - I incorrectly assumed that commonArgs was propagated everywhere. Of course, it's not picked up by cargoFmt by default, as that depends only on src. Ideally the log line could print the name of the task it's going to use, but I have my way out.

[ipetkov]

Ideally the log line could print the name of the task it's going to use, but I have my way out.

As nice as that would be, it's a bit of a chicken-and-egg problem since this helper is only being used to name the derivation if there wasn't a name specified already...

I think the best thing we can do is suggest how to use --show-trace to figure out the source of the warning