Downstream version override caused problems

[mmatrosov]

I have restsdk/2.6.0-1, which depends on boost/1.58-1. Note that this "-1" part is our "revisions" that allows us to achieve build reproducibility. We updated boost to version 1.66 and created boost/1.66-1. We also rebuilt restsdk with this version and obtained restsdk/2.6.0-2, which depends on boost/1.66-1. Ok, then in my conanfile for solution I updated boost to boost/1.66-1, but I forgot to update restsdk to restsdk/2.6.0-2 and I still had restsdk/2.6.0-1 instead. I would expect, that conan issues an error, that restsdk/2.6.0-1 requires boost/1.58-1, while I have boost/1.66-1 in my conanfile. However, instead conan installed packages just fine and I spent some time figuring out what's going on! Why conan did not warn me?..

[lasote]

Everything you specify in the conanfile is interpreted as a possible override. That is the way the final user gets fool control of the dependency graph. Probably there is some message in the output about the overridden boost.

[mmatrosov]

Ok, I see. However, this behavior was quite inconvenient for me. Is there a way to change it?

[lasote]

Not currently.

[mmatrosov]

Everything you specify in the conanfile is interpreted as a possible override.

By "conanfile" you mean conanfile used for conan install?

In my example, when restsdk/2.6.0-1 is installed, is it going to trigger installation of corresponding boost/1.58-1? Is it going to somehow access recipe from boost package? I'm just not sure how conan interprets dependencies in conanfile (used for conan install) versus dependencies in recipes.

[lasote]

By "conanfile" you mean conanfile used for conan install?

Yes

In my example, when restsdk/2.6.0-1 is installed, is it going to trigger installation of corresponding boost/1.58-1?

No, because your conanfile contains boost/1.66-1. Conan computes the whole graph of recipes but ovewritting the dependencies with the specified in the consumer conanfile. So boost/1.58 shouldn't be installed because it is overwritten by boost/1.66-1.

[symtor]

I have a similar problem with version incompatibilities in my package's dependency graph: Some dependencies of the main package require different versions of Eigen, which prints a warning message of the type
OpenCV/3.4.2-0@org/stable requirement Eigen3/3.3.3-4@org/stable overridden by Ceres/1.2.0-0@org/stable to Eigen3/3.3.3-5@org/stable

We build all packages ourselves, so we have full control over the required versions and could re-build any package with the correct requirements. However, it is easy to overlook the warning message (particularly in the CI) and introduce an incompatible combination of versions. Is there any way to make my recipe throw/fail when it encounters incompatible package requirements, instead of just printing a warning message? That would greatly reduce our risk of linking incompatible binaries.

[lasote]

There is no currently a mechanism for error on an override, but I think it could make sense to introduce a conan.conf entry for that. I'll talk with the team. Thanks

[DavidZemon]

I'd like an error on override too, but please don't make it (only) a global setting. That is not a personal preference but rather team-by-team requirement that will need to be changed based on what project you're developing at the moment. Think about the case of a professional developer that also works on open source software in his/her free time.

[danimtb]

@lasote

Everything you specify in the conanfile is interpreted as a possible override.

I don't think the behavior of Conan should be this one. You should specify it clearly in you conanfile that that requirement it is an override instead of a normal requirement. Otherwise, Conan should error a conflict!

I think this is the main problem reflected on this issue and should be solved before creating a config entry to raise errors in those cases.

[jgsogo]

I'd like an error on override too, but please don't make it (only) a global setting. That is not a personal preference but rather team-by-team requirement that will need to be changed based on what project you're developing at the moment. Think about the case of a professional developer that also works on open source software in his/her free time.

@DavidZemon I have different virtual environments for personal/hobby projects and for professional ones, switching one to other modifies some environment variables so I do not mix both workspaces (I change CONAN_USER_HOME, for example, so it changes my conan.conf).