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!

[jave27]

Our team just came across a use case for this as well. We've built up a system to generate the packages that we need for all OSes simultaneously, but because some recipes have different dependencies on an OS/arch basis, we need to first build and upload the dependencies for those targets before we can build the desired library (in this case, b2 being needed for boost).

We also publish packages in a different format for our projects which haven't converted to using Conan recipes yet, and those projects wouldn't need b2, they would just need boost.

Knowing if those dependencies exist on the server is a simple conan search -q 'os=Windows and arch=x86_64', so we can work around it, but having a dry-run option which would output JSON showing what dependencies are missing would also be nice for cases when the recipe is updated.

[memsharded]

Hi all,

This will be the conan graph info sub-command in 2.0.
It does everything that a conan create or conan install does, except building from source or installing binaries.
It is able:

• To build the dependency graph for a configuration
• Detailed json dumps of the graph
• Check package_ids, computes compatible_packages, checks remotes for packages and updates.
• Work with lockfiles, read them, use them, generate them
• Capture system_requires
• Force the installation of sources
• Dump the graph, even if there are version conflicts, also to html and json.
• Compute the build-order with conan graph build-order subcommand
• Merge build-orders with conan graph build-order-merge subcommand

That is already there for testing and feedback in the released beta. Please test it and report if necessary.
I am closing this ticket as solved with this command (better than a --dry argument to create/install)