Conan: Question: Overriding downstream version ranges

Created on 18 Jul 2019  路  5Comments  路  Source: conan-io/conan

To help us debug your issue please explain:

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

Conan version 1.17.0
OS: Ubuntu 18.04

We are currently using a lot of version ranges in all of our conanfiles, typically in the following form e.g. [~1.x], this works well for our purposes.

The problem arises when we want to test a branch of one of our libraries, i.e. one that does not have a version associated with it. An example:

appA: 
   - requires libB/[~1.x]
   - requires libC/[~1.x]
libC:
   - requires libB/[~1.x]



md5-aaf5adc00b1bb9d12716cf3aab205e8b



appA:
  - requires libB/<my_branch>
  - requires libC/[~1.x]



md5-7196f745b6171d8012a165079432b46b



libC:
  - requires libB/[~1.x]

This will raise a conflict:
ERROR: Version range '~1.x' required by 'libC/1.0.0@mychannel/stable' not valid for downstream requirement 'libB/my_branch@mychannel/stable'

I am aware that we could use the include_prerelease feature for this but that would require us to specify that in every conanfile (also conanfiles of released libraries) just so that we can test new versions occasionally.

The behaviour if you don't use version ranges is that the top-level conanfile overrides the versions specified in its dependencies. I think that the same behaviour if you do use version ranges would be very useful as well as make the behaviour more consistent across the board.

Does this seem like something that is possible?

low graph medium

Most helpful comment

5713 is merged to incoming Conan 1.20, it will be available soon 馃帀

All 5 comments

The behaviour if you don't use version ranges is that the top-level conanfile overrides the versions specified in its dependencies. I think that the same behaviour if you do use version ranges would be very useful as well as make the behaviour more consistent across the board.

I agree with you, I think that overridden dependencies don't need to satisfy any given version range.

I'm reproducing the issue described and the output is as follows:

WARN: libC/1.0@issue/testing requirement libB/[~1.0]@issue/testing overridden by app/1.0@issue/testing to libB/my_branch@issue/testing 
ERROR: Version range '~1.0' required by 'libC/1.0@issue/testing' not valid for downstream requirement 'libB/my_branch@issue/testing'

I've found a problem related to this: we already have tests checking this behavior, so we need to decide if it is a bug or we need to wait for Conan v2.0. As always, someone could trust in this behavior and consider any change a regression.

For some reason I did not get notified by GitHub of the latest activity in this ticket and had gone off on my own to try and fix it. I came up with a solution but I think yours is much neater.

I take your point about someone trusting in this behaviour but I think you could say that about any bugfix. There is also the CONAN_ERROR_ON_OVERRIDE environment variable which could be used to reinstate the old, buggy behaviour (albeit with other side effects).

BTW I tested your PR and it worked fine for our use case so thanks a lot!!

It would be great to have that one for feature testing since they're prerelease versions. :slightly_smiling_face:

5713 is merged to incoming Conan 1.20, it will be available soon 馃帀

Was this page helpful?
0 / 5 - 0 ratings

Related issues

liberforce picture liberforce  路  3Comments

zlalanne picture zlalanne  路  3Comments

uilianries picture uilianries  路  3Comments

db4 picture db4  路  3Comments

niosHD picture niosHD  路  3Comments