Closed JackRenner closed 2 years ago
Hi @JackRenner
I am afraid this is not possible. Such "smart" dependency resolution is an algorithm that requires backtracking and is known to be NP-hard. Given that the resolution of every node in the graph requires frequently to download, unzip, install, load and interpret a python or several python files, and evaluate a few methods of that python file, that makes this problem intractable in practice.
It is also true that in practice, users have versioning and continuous integration strategies to control how new versions are managed, typically either being conservative or trying to continuously move forward. In your scenario, different approaches could happen:
pkg_a/1.2.0
(use lowercase to be 2.0 ready), tries to depend on shared_package/3.0.0
, but it fails to integrate in the final product (your conanfile.txt), so it is rejected, and it is forced to continue on the shared_package/2.3.4
version. shared_pakage/3.0.0
. It might need to create new binaries for some packages, and some might need code changespkg_a/[>=1.0.0 <1.2.0]
Dang. I figured that this would be challenging to implement and use practically. I appreciate the response, and everyone's hard work on conan, its a fantastic tool!
Dang. I figured that this would be challenging to implement and use practically. I appreciate the response, and everyone's hard work on conan, its a fantastic tool!
Thanks for your kind words and following up with feedback on this issue! :)
I am looking to use version ranges for several of my development packages to get each of their latest versions, but I want to restrict the version search by the version of their primary shared dependency.
So if we have
pkgA/1.0.0
andpkgA/1.1.0
built withshared_package/2.3.4
, butpkgA/1.2.0
built withshared_package/3.0.0
, I would like conan's version range resolution to selectpkgA/1.1.0
.Is this currently possible, or is there another way to achieve the same result?