Prevent overriding dependency versions

[salessandri]

My situation is the following:

• PROJECT/0.2.0 -> B/0.1.0, C/0.1.0, D/0.1.0
• B/0.1.0 -> D/0.1.0
• C/0.1.0 -> D/0.1.0

Until then, everything's fine. Now there's a new version of B that leads to the following:

• PROJECT/0.3.0 -> B/0.2.0, C/0.1.0, D/0.1.0
• B/0.2.0 -> D/0.2.0
• C/0.1.0 -> D/0.1.0

I am defining full_version_mode() everywhere. If PROJECT did not depend on D, Conan would fail saying that the dependencies are incompatible. But if D happens to be a dependency of the project too, then it will override any dependencies' usage of D to its version.
Is there a way to prevent this from happening and have it fail if there are any 2 versions of the same library that are different/incompatible?

If I do not set build=missing it's ok for me because it will basically not find the package_id for the library with the overridden dependency. But I'd rather have it fail at the dependency graph analysis and re-enable the build=missing option.

• I've read the CONTRIBUTING guide.
• I've specified the Conan version, operating system version and any tool that can be relevant.
• I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

[lasote]

Hi @salessandri!

Is there a way to prevent this from happening and have it fail if there are any 2 versions of the same library that are different/incompatible?

No, if the project declares the override/require to D it will use it in the whole graph, in general, any intermediate require resolves conflicts upstream. We don't have a mechanism to block the overrides.

I don't know if it helps but if you want to automate the check task you could run a conan info . --json output.json, in the output you will see if some binary is missing.

[  
   {  
      "revision":"95fa8a06e701a3827a999668979b5e2e",
      "reference":"LIB_B/0.2.0@user/channel",
      "is_ref":true,
      "display_name":"LIB_B/0.2.0@user/channel",
      "id":"75448e85a06e45c0071d9853d912f348a78c06c9",
      "build_id":null,
      "recipe":"Cache",
      "binary":"Missing",
      "creation_date":"2019-02-06 08:30:19",
      "required_by":[  
         "conanfile.py (PROJECT/1.0@None/None)"
      ],
      "requires":[  
         "LIB_D/0.1.0@user/channel"
      ]
   },
   {  
      "revision":"8fcfcefd1d676b8a78e3d1d5fd4cb11e",
      "reference":"LIB_C/0.1.0@user/channel",
      "is_ref":true,
      "display_name":"LIB_C/0.1.0@user/channel",
      "id":"75448e85a06e45c0071d9853d912f348a78c06c9",
      "build_id":null,
      "recipe":"Cache",
      "binary":"Cache",
      "creation_date":"2019-02-06 08:30:17",
      "required_by":[  
         "conanfile.py (PROJECT/1.0@None/None)"
      ],
      "requires":[  
         "LIB_D/0.1.0@user/channel"
      ]
   },
   {  
      "revision":"ff526ddc6ece04b18e4637ef41a1ca88",
      "reference":"LIB_D/0.1.0@user/channel",
      "is_ref":true,
      "display_name":"LIB_D/0.1.0@user/channel",
      "id":"5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9",
      "build_id":null,
      "recipe":"Cache",
      "binary":"Cache",
      "creation_date":"2019-02-06 08:30:16",
      "required_by":[  
         "LIB_C/0.1.0@user/channel",
         "LIB_B/0.2.0@user/channel",
         "conanfile.py (PROJECT/1.0@None/None)"
      ]
   },
   {  
      "reference":"conanfile.py (PROJECT/1.0@None/None)",
      "is_ref":false,
      "display_name":"conanfile.py (PROJECT/1.0@None/None)",
      "id":"912d0e9c6afb67d0386f383a550ba83fe0fa3950",
      "build_id":null,
      "requires":[  
         "LIB_B/0.2.0@user/channel",
         "LIB_C/0.1.0@user/channel",
         "LIB_D/0.1.0@user/channel"
      ]
   }
]

[michaelmaguire]

I think I am struggling with this issue too.

Can I ask what you mean by:

I am defining full_version_mode() everywhere.

Do you mean that in the package_id() of PROJECT you are implementing:

def package_id(self):
    self.info.requires["B"].full_version_mode()
    self.info.requires["C"].full_version_mode()
    self.info.requires["D"].full_version_mode()

as mentioned in:

https://docs.conan.io/en/latest/creating_packages/define_abi_compatibility.html#versioning-schema

[salessandri]

@michaelmaguire Yes, that's what I'm doing but in an easier way:

def package_id(self):
    self.info.requires.full_version_mode()

That makes it apply to all the requires. Also I need to run conan without any --build=missing arguments. Otherwise, it will try to build the dependency with the updated dependency and I actually want conan install to fail.

I really hope they add a way to explicitly override the arguments from the top level but not do it silently.

[lasote]

Related to #2800

[lasote]

We are introducing an opt-in conan.conf config to fail when an override happen and it is no explicit (not specified with the "override"). For the next 1.14 release.

[jgsogo]

Hi! I'm implementing this behavior in the linked PR, I wanted to share with you the proposed config variables names I am using:

• general.raise_on_override
• CONAN_RAISE_ON_OVERRIDE

If anyone of you have a better idea for the naming, please, contribute. Thanks!

[salessandri]

I'm fine with those.

But, it seems that raise is too coupled with Python's raise exception. Something like error_on_override seems more natural to someone without any python knowledge.

[jgsogo]

@lasote, I'm not sure about this functionality (about the explicit override), the docs says:

override (Optional, Defaulted to False): True means that this is not an actual requirement, but something to be passed upstream and override possible existing values.

So, in the use-case exposed above, enabling the error_on_override config, if I want to actually override and depend on the library too I would need to duplicate the requirement and then Conan raises with a Duplicated requirement error 😕

[lasote]

That is what I tried to explain to you in the last whiteboard. That use case is missing. And we agree on just enabling the way to raise. There is a missing way to say "I'm depending on this and I know I'm overriding, so don't raise".