Profile setting is lost when recursively calling cargo make

[Sushisource]

Describe the bug
The profile setting is lost when recursively calling cargo make (ex: to go from workspace=false mode to workspace=true)

To Reproduce
This script repros the bug in a cargo workspace with at least two members

[env]
CARGO_MAKE_EXTEND_WORKSPACE_MAKEFILE = "true"

[tasks.runme]
workspace = false
dependencies = ["build-native-flow"]
command = "echo"
args = ["${CARGO_MAKE_PROFILE}"]

[tasks.build-native-flow]
workspace = false
category = "Build"
# Recursively call cargo make to go back to using workspace mode, thus running build-native
# for all non-excluded crates in the workspace
command = "cargo"
args = ["make", "--profile=${CARGO_MAKE_PROFILE}", "build-native"]

[tasks.build-native]
description = "Runs the rust compiler."
category = "Build"
command = "echo"
args = ["${CARGO_MAKE_PROFILE}"]

Output:

(master) λ cargo make --profile production runme                                                                                      (cargomaketest) 16:58:04
[cargo-make] INFO - cargo make 0.21.0
[cargo-make] INFO - Using Build File: Makefile.toml
[cargo-make] INFO - Task: runme
[cargo-make] INFO - Profile: production
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: build-native-flow
[cargo-make] INFO - Execute Command: "cargo" "make" "--profile=production" "build-native"
[cargo-make] INFO - cargo make 0.21.0
[cargo-make] INFO - Using Build File: Makefile.toml
[cargo-make] INFO - Task: build-native
[cargo-make] INFO - Profile: production
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: workspace
[cargo-make] INFO - cargo make 0.21.0
[cargo-make] INFO - Using Build File: Makefile.toml
[cargo-make] INFO - Task: build-native
[cargo-make] INFO - Profile: development
[cargo-make] INFO - External file not found or is not a file, skipping.
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: build-native
[cargo-make] INFO - Execute Command: "echo" "development"
development
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 0 seconds.
/home/spencer/scratch/cargomaketest
[cargo-make] INFO - cargo make 0.21.0
[cargo-make] INFO - Using Build File: Makefile.toml
[cargo-make] INFO - Task: build-native
[cargo-make] INFO - Profile: development
[cargo-make] INFO - External file not found or is not a file, skipping.
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: build-native
[cargo-make] INFO - Execute Command: "echo" "development"
development
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 0 seconds.
/home/spencer/scratch/cargomaketest
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 0 seconds.
[cargo-make] INFO - Running Task: runme
[cargo-make] INFO - Execute Command: "echo" "production"
production
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 0 seconds.

Thanks again! Sorry for the slew of bugs, but it's only because I'm finding your tool so useful!

As a related note, I think the way workspaces are handled in general is a ubit confusing and doesn't mesh well with the way cargo natively does things. In my makefile at least, almost everything is workspace=false. I would advocate for making that the default, honestly, or have an option to make it the default.

Additionally, simply being able to force workspace=true into tasks that need it (unless overridden by the command line when directly calling the task) would make more sense to me than having to do this odd recursive calling trick.

That said, it seems like cargo does pretty much everything you'd want by default without needing to go run things explicitly in each sub directory, hence why workspace=false seems like it ought to be the default to me.

[sagiegurari]

profile value is provided on command line and not as env, so that is why you are facing the issue.
can you try changing the task to:

[tasks.build-native-flow]
workspace = false
category = "Build"
# Recursively call cargo make to go back to using workspace mode, thus running build-native
# for all non-excluded crates in the workspace
run_task = { name = "build-native", fork = true }

this is both much simpler and shorter and also ensures that all original settings are preserved.

as for workspace=true/false, by default i believe that when you want to run some tool (formatting/build/test/clippy/...) you want to run them on each member so that is why by default, when in a workspace, it is invoking the task on each member.
having workspace level tasks are more rare and i'm not sure if maybe it can be setup differently to be simpler. i'll have to look at an example makefile to try to help.

[Sushisource]

Thanks for the solution! I thought run_task might be what I needed...

I think the reason workspace=false by default makes sense to me is that it only applies to rust code, but the native rust tools already do this job for you quite well.

That is to say, if I run cargo build or cargo fmt at the root of my workspace, it already does the job of building/formatting all workspace crates. So, in my case at least, pretty much every task is a workspace level task - including this build one, which I ended up changing to be a workspace level cargo build and cargo just handles everything. It also makes the output a bit cleaner.

Perhaps a more general "I would like these tasks to iterate over these sub-directories, which may also contain makefiles", would make sense? That doesn't couple so heavily with rust workspaces specifically, but still gives you that power when needed.

Just some spitballing. Thanks again!

[Sushisource]

Ah, another note, with run_task. The profile seems to get quotes added around it, which seems to break my env.production section. (Fixable by redundantly specifying [env."\"production\""])

[cargo-make] INFO - Profile: production
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: pp
[cargo-make] INFO - Running Task: cargo_make_run_fork
[cargo-make] INFO - Execute Command: "cargo" "make" "--disable-check-for-updates" "--no-on-error" "--loglevel=info" "--profile=\"production\"" "--allow-private" "--skip-init-end-tasks" "--makefile=XXX" "some-other-task"
[cargo-make] INFO - cargo make 0.21.0
[cargo-make] INFO - Using Build File: /home/spencer/dev/thermite/Makefile.toml
[cargo-make] INFO - Task: some-other-task
[cargo-make] INFO - Profile: "production"

[sagiegurari]

oh, that's a bug. i'll check that out. thanks

as for the workspace=false, i opened issue #264 which will allow you to disable it globally via workspace level env block. that i think, should give you a very simple solution.

[sagiegurari]

@Sushisource the profile name bug should be fixed now in the 0.22.0 development branch.
you can test it to ensure its ok.

[Sushisource]

@sagiegurari Confirmed fixed. Thanks!

[sagiegurari]

thanks a lot for confirming.

[sagiegurari]

@Sushisource cargo make 0.22.0 has now been published with the profile fix.

[daxpedda]

Using workspace = false doesn't allow me to let tasks run for every member.
So I wanted to detect profiles and pass them through with environment variables ([env.profile]), but this doesn't work when used in combination with CARGO_MAKE_EXTEND_WORKSPACE_MAKEFILE = true, which I need so I don't have to duplicate tasks for every member in a workspace.

So is there a reason why profiles aren't passed down? Is this by design?