Conan: Add `dry-run` options to all commands

[cleeland]

One very handy way to understand new tools is to be able to peek "under the hood" and see what actions the tools take for particular ways of being invoked. It would be nice for conan to have --verbose and --dry-run flags which would,respectively, describe what conan is doing under the hood (--verbose) and not actually do the actions (--dry-run).

I have tried using CONAN_TRACE_FILE, but it doesn't seem to provide the same information as what I'd expect --verbose to do. And I've found nothing similar to --dry-run.

[memsharded]

I agree that a verbose option would make sense and improve the user experience, and is doable (I suggest not to do it all at once, but to introduce some output.verbose method that will be no-op if not verbose, and use it thoroughly along the code while coding.

While I agree that --dry-run could be useful, the truth is that it is not that simple. Implementing a conan install --dry-run would be a challenging task, because it requires retrieving files, storing them in the cache, retrieving or building the binaries.... too much, especially for the value. My recommendation would be not to address it, unless a very specific use case and its motivation is outlined, as it was done with the upload, which now has the --skip-upload that would inhibit the upload. Note however that this is not a dry-run option, because it is actually creating the tgz files that will be uploaded, but this is fine, as the users didn't want to have to re-tgz them (slow), but mainly check that everything looked good for all packages before uploading all of them

[cleeland]

My recommendation would be not to address it, unless a very specific use case and its motivation is outlined, as it was done with the upload, which now has the --skip-upload that would inhibit the upload.

Note that the output from conan upload --skip_upload is identical to the output from conan upload without the option.

[cleeland]

Implementing a conan install --dry-run would be a challenging task, because it requires retrieving files, storing them in the cache, retrieving or building the binaries.... too much, especially for the value.

Why would a dry-run require building anything, or even retrieving anything? It needs to tell me what it would retrieve, much like apt or yum can do. It doesn't need to actually fetch the packages.

[lasote]

@cleeland In conan, the requirements can be conditional, to your settings, to your options, to any code in your recipe. So it needs the recipe to know the requirements.

[michaelmaguire]

I really like the --verbose idea, and would hate to see it get caught in discussions about feasibility of --dry-run.

Permission to reduce scope of this ticket to just --dry-run and use #5765 for just --verbose?

[cleeland]

I support the reduced scope.

[foundry-markf]

Just to add to this, I was also thinking about dry-run 'conan create' calls this morning.

The context behind it is that we have a lot of our own recipes, and we tend to stay on an older version of Conan for stability, but I would like to know if there's any incompatibility with the _Python_ side of the recipes, without paying the cost of building all of the packages again, when the Conan version does change. (And I would prefer to track newer versions.)

For instance, I know that there was a breakage in some of our recipes written before Conan 1.28 was released, which raises an exception when built with a Conan from 1.28 onward. The logic causing it isn't easily greppable, and I've not had time to go and hunt down other instances of this. And that's just one instance of a breakage.

The idea I was mulling over this morning is to do a 'dry-run' across all of our recipes (without modification from source control), as new Conan versions are released, watching for breakages. It'd also be useful with CONAN_V2_MODE enabled, so that I can keep an eye on that too. It'd be quick and dirty, without needing to hog build resources rebuilding packages I don't need to.

So, I wouldn't need an install step to pull down dependencies to the local cache, but would be good to check that package_ids as defined by the recipe requirements were available in an Artifactory remote.
It wouldn't need to build anything, just display the commands that would be run.
Any self.copy would just display intent, rather than failing to find source files.

Does that help towards this, @memsharded?

unless a very specific use case and its motivation is outlined

Thanks!