Use of older toolchain versions is highly problematic if workspace default is set to nightly

[vrurg]

Describe The Bug

If a workspace is defaults to nightly (rustup override set nightly) then cargo creates v4 Cargo.lock. But when a task has its toolchain set to some older version and it's executing cargo then the following happens:

[cargo-make] INFO - makers 0.37.23
[cargo-make] INFO -
[cargo-make] INFO - Build File: Makefile.toml
[cargo-make] INFO - Task: bugtest
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Execute Command: "rustup" "run" "1.77" "cargo" "test"
error: failed to parse lock file at: /[...]/Cargo.lock

Caused by:
  lock file version `4` was found, but this version of Cargo does not understand this lock file, perhaps Cargo needs to be updated?
Error while executing command, exit code: 101

To Reproduce

[tasks.bugtest]
    args      = ["test"]
    command   = "cargo"
    toolchain = "1.77"

[sagiegurari]

@vrurg thanks. do you have a suggestion here? because it sounds to me like workspace and task have conflicting requirements and cargo is not handling them well.

[vrurg]

I'm not really sure. Besides, I suspect that there was another factor which, as I suspect, may have contributed to the situation: it is likely that the default toolchain was accidentally set for an individual crate in the workspace. I was in a rush and didn't check out this carefully enough, but resetting the default in all crates was seemingly helpful. Anyway, even if it was the case, it's not an illegal situation and better be considered too.

My approach for eliding problems with the lock is to remove it before invoking any lock-dependent task. This is a necessary step when testing of multiple compiler versions is involved.

I currently see a couple of ways of dealing with the issue.

1. Most tedious one: backup+remove and restore the lock before and after performing operations that update it. Like, say, meta reading. While being a bit doubtful about the restore step, I'd better have it since rebuilding the lock may result in updated minor crate versions which can be an undesired side effect.
2. Have an option which is, when set, would result in the lock being unconditionally removed per task before its command or script is executed.

Perhaps, just the backup/restore would be sufficient to eliminate the problem altogether, but only testing would tell.