[bug] Wrong advice when there are dependency conflicts

[ericriff]

Describe the bug

I have a simple project where there is a dependency conflict. When I create a lockfile, conan errors out and tells me to run conan graph info to better understand the problem. This cmd also errors out.

Os: Ubuntu 22.04
Conan: 2.3.0

How to reproduce it

conanfile.txt

[requires]
pybind11/2.12.0
fake-package-1/1.0
fake-package-2/1.0

Where fake-package-1 has this conanfile

from conan import ConanFile


class Intro(ConanFile):
    name = "fake-package-1"

    def requirements(self):
        self.requires("pybind11/2.11.1")

and fake-package-2 has

from conan import ConanFile


class Intro(ConanFile):
    name = "fake-package-2"

    def requirements(self):
        self.requires("pybind11/2.10.4")

So I directly require pybind11/2.12.0, fake-package-1 requires for pybind11/2.11.1 and fake-package-2 requires pybind11/2.10.4.

I started with a simple lockfile which only contains the direct pybind11/2.12.0 requirement:

{
    "version": "0.5",
    "requires": [
        "pybind11/2.12.0#1bf487c19d580200ba9b74afcc4174b4%1711607911.876"
    ],
    "build_requires": [],
    "python_requires": [],
    "config_requires": []
}

The first problem I see is that conan only reports one conflict:

conan lock create .
Using lockfile: '/workspaces/module-template/conan.lock'

======== Computing dependency graph ========
Graph root
    conanfile.txt: /workspaces/module-template/conanfile.txt
Requirements
    fake-package-1/1.0#aff3ad324fa62b5e1ccc1b916845fcdb - Cache
    pybind11/2.12.0#1bf487c19d580200ba9b74afcc4174b4 - Cache
ERROR: Version conflict: Conflict between pybind11/2.11.1 and pybind11/2.12.0 in the graph.
Conflict originates from fake-package-1/1.0

Run 'conan graph info ... --format=html > graph.html' and open 'graph.html' to inspect the conflict graphically.

The second problem is that it says the conflict originates from fake-package-1, but it doesn't say with which other package is conflicting. For this case it is simple, but it would be harder to track down on a more realistic project with many requirements.

But the main problem is that the advice conan gives me to debug this issue, doesn't work

conan graph info .
Using lockfile: '/workspaces/module-template/conan.lock'

======== Computing dependency graph ========
ERROR: Requirement 'fake-package-1/1.0' not in lockfile

I think that Conan should:

1. Report all conflicts, if there are more than one
2. List the pair (or more) packages that introduce the conflicts, not just one
3. Improve this helper message conan graph info ... by replacing the three dots with something like <conanfile-path>
4. Give the correct suggestion

[memsharded]

Hi @ericriff

Thanks for your feedback.

1. Report all conflicts, if there are more than one

I am afraid this won't be possible. It is not simple to do this, conflicts break the integrity of the graph, so even trying to continue will not return all conflicts, and it might even be throwing a bunch of false positives (or at least confusing ones) after the first one, kind of C++ compilation errors with templates. It has also some technical challenges, as the conflict state is not really stored in the dependency graph nodes, so it will require a relatively large effort.

And from our experience, it doesn't really make a huge difference, because they are also typically resolved one by one, iteratively.

2. List the pair (or more) packages that introduce the conflicts, not just one

This is also quite challenging with the current graph computation process, most information is overriden and the "state" is not there. It can be confusing too, and there are many factors that are involved like package visibility, overrides, forces and many more. This is not something that can be trivially listed in text, and this is why the html graph representation is preferred.

3, 4

I agree that it would be better if the helper message could be improved. But there are also quite some challenges, when the conflict actually occurs, it is not that simple to the exact command that would be necessary, as there are many different inputs, like conan install <path> or conan install --requires=pkg/version or conan install --tool-requires=tool/version, but when a conflict occurs, everything has been mapped to a similar "dependency graph", it is not like the full command has been propagated to the point the conflict happen and then it can be used to print the exact line.

In your case, you are also seeing the effect of using a partial lockfile, and conan lock create will input partial lockfiles by default. But the conflict detection and message is also the same for all commands (install, create, graph info, graph build-order, lock create), so it cannot easily know what is the exact case that is happening.

I will have a look if there are some low hanging fruits that could be used to improve the message, but if not possible, this might be considered as a UX improvement request and might not be changed or just clarified in the message. Thanks for your suggestion!

[memsharded]

I have been investigating this a bit:

Run 'conan graph info ... --format=html > graph.html' and open 'graph.html' to inspect the conflict graphically.

Is a good default and work fine in many cases, replacing the ... with the user arguments that caused the conflict.

There are only few scenarios that will require adding arguments, like the above requires:

• Using a lockfile
• The lockfile is not complete, it is partial
• The conflict originates in a conan lock create command that defaults to --lockfile-partial
• And then the conan graph info ... will fail because the argument --lockfile-partial is not provided.

I have tried to add something like conan graph info <args>, and <args> are the previous command arguments, adding "--lockfile-partial" if the command was "conan lock" ..., but I am quite concerned that this will be confusing a lot to many users that are not in that edge case.

I have also checked, propagating the information about the command and arguments to the point that the conflict message is printed will be cluttering the codebase a lot, I don't think it is worth the value, maintainability is very important.

So I think that even if the message is not perfect for 100% of the cases, the effort and side effects of trying to improve it for some of the corner cases is too much, so better leave this as-is at the moment. Thanks very much for the feedback!