[question] Override requirements from command line

[realbogart]

What is your question?

Is it possible to override a requirement when running conan install?

I noticed that you can set replace_requires and replace_tool_requires in the profile:
https://docs.conan.io/2/reference/config_files/profiles.html

I also noticed that in Conan 1.x there was a command line argument called --require-override that seems to do just that. But what about Conan 2.x?

Thanks!

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @realbogart

Thanks for your question.

The cli argument has been removed in Conan 2, it was terrible regarding UX. The problem with it is that it is very important to be consistent across all commands (conan lock, conan install, conan create, conan graph info, conan test), and this was a constant source of issues, debugging and support, and specially regarding reproducibility. The only way to mitigate this was to force the definition of replace_requires to be in the profiles.

[realbogart]

Hi @memsharded,

Thank you for the quick reply.

Would it make sense to be able to pass replace_requires, replace_tool_requires etc through the cli, similar to how you can pass other profile constructs like settings with -s and options with -o? They are already consistent across the commands that you listed and maybe these could be too?

We are trying to automate the testing of new package versions/revisions in different consumer projects in our CI system. For this we need a way to override the requirements set in these projects. Do you have any other suggestions on how to achieve this?

Thank you for your help.

[memsharded]

Would it make sense to be able to pass replace_requires, replace_tool_requires etc through the cli, similar to how you can pass other profile constructs like settings with -s and options with -o? They are already consistent across the commands that you listed and maybe these could be too?

Changing something as the -s build_type=Debug or -o *:shared=True is more close to the typical developer flow, commands and understanding, for example, when working with CMake, you will be doing either -DCMAKE_BUILD_TYPE=xxx or cmake --build . --config Debug (for multi-config), so it kind of makes sense that developers can pass it in the command line.

On the other hand, some things from profiles like [tool_requires] or [replace_requires] are way more structural and they are not something that developers typically deal when developing.

We are trying to automate the testing of new package versions/revisions in different consumer projects in our CI system. For this we need a way to override the requirements set in these projects. Do you have any other suggestions on how to achieve this?

Yes, this seems a different use case than the one that replace_requires are intended to address. Basically, replace_requires are useful for:

• Cases where some dependencies want to be replaced for API compatibles alternatives (like zlib-ng as a replacement for zlib) without modifying all recipes in the graph
• Cases when we want to replace some dependency with a system one (like openssl provided by a sysroot in a cross-compilation for embedded scenarios), and we need to provide a bit of extra info about that system openssl library.
• To temporarily resolve conflicts from dependencies we don't control or that we do control but need a faster/immediate conflict resolution.

The case you are exposing is more a traditional versioning mechanism, there are new things that we want to test, and we should be able to test them. This is approached with several mechanisms:

• Using version ranges, that will automatically accept as a dependency new versions of the dependencies that fit in the ranges. Then to test them, it is only necessary to make them available, no necessary to configure or change anything in the configuration or profiles
• Typically, using different server repos is a recommended approach. The new version/revision to test is put in a separate "build" repo, and then the CI tests the dependants including this "build" repo. Only when this new version/revision is accepted, everything is green, the new version is copied into the main "develop" repo that all developers and CI will be using by default.
• It is possible to use the prerelease mechanism, with a conf that allows to accept or reject them, to test special cases of new version pre-releases without affecting other developers and CI, even if the prereleases are uploaded to the "develop" repo.
• Lockfiles can be used in Conan 2 way more easily than in Conan 1 to control what specific version is used in testing. This allows for safer concurrent CI jobs testing different versions or revisions of the same package. The only constraint is that the versions/revisions in the lockfile have to fit in the version range of the consumers, but otherwise the lock add mechanism, or capturing a lockfile in the conan export or conan create of the package can be applied to downstream consumer graphs with --lockfile-partial easily.

Please let me know if this clarifies a bit the approach. It is true that we need to complete the docs in this regard, this is a pending task, hopefully can be done soon.

[realbogart]

Thank you for that detailed answer, @memsharded!

I will look closer at your suggestions to see if they can be applied to our setup.

[memsharded]

Good, thanks for the feedback.

I think we can close this question as responded then, don't hesitate to create new tickets for any further question or issue that you might have. Thanks!