[bug] Conan install/graph explain don't find package because they don't filter based on settings/options before selecting package candidate

SaarYogev commented 3 months ago

Describe the bug

Environment Details:

OS: Ubuntu 22.04
compiler: prebuilt binaries, irrelevant
Conan version: 2.4.1

profile: (again, doesn't matter much because I'm using prebuilt binaries)

[settings]
arch=x86_64
build_type=Debug
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
[options]
branch=feature/conan_recipe
fPIC=True
shared=False

Description

I'm trying to install the latest package (let's call it A) with the relevant settings and options, such as Debug build_type. To do that, I'm calling conan install --requires="A/[~1,include_prerelease]" -s build_type=Debug. What I expect to get is the package I uploaded that has the Debug build_type. What I get instead is a random version of A, that has a Release build_type, as graph explain tells me.

I debugged a bit, and saw the Conan only filtered the package based on the name and version pattern, and left the filtering based on settings and option until after the package candidate is selected. As you can see in range_resolver.py:60, there are no options/settings even passed, only a (version) pattern.

Another way in which I found it's an issue with the filtering, and not recognizing the package itself, is that Conan successfully installs the correct package if I restrict the version pattern to include only packages which include the settings and options I want.

As far as I know this is not a well known or documented behaviour, and I think it should be changed, so packages are filtered based on settings and options in addition to the version pattern, and only then the latest package is selected for the graph.

My use case

I'll explain my use case here, so if you think you can there's a better way to achieve what I need without changing Conan, I am open to suggestions 😄 .

There are two reasons that each version does not include every possible setting/option combination: 1.I tag prerelease versions based on a timestamp, so developers working on a feature would get a package automatically, without tagging it by hand. The timestamp also keeps it ordered, as I'm allowed to order by prerelease information according to the semantic versioning spec. Since release and debug configurations don't get at the exact same time, each prerelease version only has one of them, and I expect to just get the latest prerelease version using release or debug based on my request.

I add an option to indicate the branch this package was created from, which is important to differentiate prerelease packages from different feature branches. I know I can put it in the prerelease, but it was not essential to ordering so I preferred not to. I can change that if required.

I appreciate your help and attention to this matter, thank you!

How to reproduce it

Upload multiple versions of your package (let's call it A) with the Release build_type, and a single one with the Debug build_type. Put on the package with the Debug build_type a version that's not the earliest or latest so it won't get picked up first by chance.
Run conan install --requires="A/[~1,include_prerelease]" -s build_type=Debug
See that it doesn't find your package, and that conan graph explain --requires="A/[~1,include_prerelease]" -s build_type=Debug says the closest binary has a Release build_type.

memsharded commented 3 months ago

Hi @SaarYogev

Thanks for your feedback.

This is not a bug, this is by design. Let me try to clarify how Conan works:

In a first step Conan computes the dependency graph of recipes + versions (+ recipe revisions)
In a second step, the package_id of every package in the dependency graph is computed. This package_id is the representation of the necessary binary. The specific versions of dependencies do affect the consumers of the packages, so it is first necessary to know the dependencies versions (fully expand the graph) to be able to compute which binary is necessary for each node in the dependency graph
In the third step, every package_id is analyzed, checking if it does exist, if is necessary to build it, if it is an invalid configuration for the current platform, or if it is existing in a server and it has to be downloaded
In the final step, each package_id binary in the graph is downloaded, built from source, etc.

Searching for a joint compatible set of existing binaries for previous versions and recipe revisions makes this problem NP complete, requiring backtracking. Every time a binary package_id is not found, the full dependency upstream graph should be invalidated and rebuilt again for the new considered version or revision. Taking into account that evaluating hypothesis in this necessary backtracking algorithm involves things as downloading files, unzipping them, loading and python-parsing them and finally executing them, this makes this problem intractable in practice. Trying to do so could result in non tolerable graph resolution times (I am talking about many hours).

The way to approach this in Conan is with different versioning and devops practices:

If a pre-release is not including the build of different binaries needed, then to not disrupt consumers (other developers or CI), then, the pre-releases are used as opt-in (do not add prereleases in requires in recipes, but activate it via conf only)
Using different server repositories. This is a standard good practice in devops, for other technologies as well. So packages that still didn't build all the binaries are uploaded to a different, secondary server repository, called for example "testing". Only when those packages are validated, they are built the different binaries needed by developers, etc, the packages are "promoted" (copied) from the "testing" server repository, to the "develop" server repository. Developers and CI jobs only use "develop" as default repository, an they add "testing" as repository only when they want to test and use those specific new packages, not ready for prime time yet.

memsharded commented 1 month ago

Hi @SaarYogev

Any further question here? Thanks for your feedback.

SaarYogev commented 1 month ago

No more questions, thank you! I changed the code I our CI to work with this, so each pipeline will create packages with all the possible configurations our users might ask for.

memsharded commented 1 month ago

Thanks for your feedback! Closing the ticket then.

Do not hesitate to create new tickets if you have any further question or issue.

conan-io / conan