To help us debug your issue please explain:
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?
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:
Conan 1.20, it will be available soon 馃帀
Most helpful comment
5713 is merged to incoming
Conan 1.20, it will be available soon 馃帀