--no-dev-deps flag edits real manifest

[taiki-e]

Using --no-dev-deps flag is recommended to avoid rust-lang/cargo#4866 if resolver = "2" doesn't set.

However, currently, using --no-dev-deps flag removes dev deps from real manifest while cargo-hack is running and restores it when finished.
If possible, this should be done without editing the manifest.

Workaround

Using unstable -Z features=dev_dep (rust-lang/cargo#7916) or -Z avoid-dev-deps (rust-lang/cargo#5133) instead of --no-dev-deps.

Note:
-Z avoid-dev-deps works well with cargo check/build/run/install, but not with cargo publish.
On the other hand, --no-dev-deps doesn't work well with cargo install.

[taiki-e]

Perhaps it needs to ban test/bench subcommands and --tests/--all-targets flags when --no-dev-deps is used. (done in #16)

Then create an empty crate for testing in the target directory like trybuild is doing.

[taiki-e]

Then create an empty crate for testing in the target directory like trybuild is doing.

Hmm, if doing this, it will not work well except for check subcommand (especially publish subcommand).

[taiki-e]

So, for now, I think it should handle the check subcommand specially. (And probably warn when used with other subcommands.)

[taiki-e]

Now that cargo-hack can handle ctrl-c properly, I think that some burden caused by this issue has been reduced.

[taiki-e]

Workaround for this is using unstable -Z avoid-dev-deps instead of --no-dev-deps.

-Z avoid-dev-deps (tracking-issue: rust-lang/cargo#5133) is an unstable feature of cargo that has almost the same effect as cargo-hack's --no-dev-deps. However, unlike --no-dev-deps, the manifest file is not edited.

FWIW:
-Z avoid-dev-deps works well with cargo check/build/run/install, but not with cargo publish.
On the other hand, --no-dev-deps doesn't work well with cargo install.

[taiki-e]

We can probably consider using -Z avoid-dev-deps or -Z features=dev_dep for some subcommands in nightly if they can guarantee some equivalent behavior.
But I'm not sure if that is the desired behavior.

[jhpratt]

With resolver = "2" stabilized (and becoming default in the 2021 edition), I don't see this as a particularly "must-fix" kind of issue.

[taiki-e]

and becoming default in the 2021 edition

BTW, at least when the workspace root is a virtual manifest, resolver = "2" does not seem to properly apply in the workspace, even if all workspace members are 2021 edition.

Therefore, in practice, it seems preferable to always specify resolver = "2" (considering the possibility that the project structure may change in the future).