Alias resolution bug with mixed Alias and fixed version and mixed requires and build_requires

[fourbft]

In the situation of three packages CA, CB and CC, where CB uses CA as requires(CA/1.0.0@...) with a fixed version / direct reference and CC uses CB as requires() and CA as build_requires(CA/ALIAS@...) via an alias, conan (version 1.16.1) fails to create CC with an error message of

ERROR: Conflict in CC/3.0.0@user/testing
Requirement CA/ALIAS@user/testing conflicts with already defined CA/1.0.0@user/testing
To change it, override it in your base requirements

even though the ALIAS points to the exact same version 1.0.0@user/testing of CA.

Here is a tarball with all needed files to reproduce the bug. Unpack and start "create_all_packages.sh" on a linux machine to reproduce the bug. (Use the contained "cleanup.sh" to clean the conan cache for a second run.)
conan_alias_bug_demo4.tar.gz

This issue is different from the situation in issue #4753 in that in this case, no different versions of the requires(CA) (in CB) and build_requires(CA) (in CC) are involved, but an alias and a direct reference to the exact same version of CA. But the issues might, of course, be related.

To help us debug your issue please explain:

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

[danimtb]

Hi @fourbft and thanks a lot for the report.

Yes, the case in which CA/ALIAS is the same as CA/1.0.0 looks like a bug, as that situation is totally valid because finally, you are requiring A for the same version in both cases. You can check this changing the build require in CC to CA/1.0.0 and it will work.

However, in the case the versions are different the error is right, as you cannot have the same package with different versions in a graph, no matter if it a require or a build require.

[fourbft]

Hi @danimtb,

You can check this changing the build require in CC to CA/1.0.0 and it will work.

yes, if you have a look at the files in the attached tar.gz archive above, this is exactly what I said in the comment in the build_requirements() function of CC/conanfile.py. So the problem seems to be, that the alias is not correctly resolved before comparison.
This might be a variation of the problem in issue #2576. (See also #2597).

However, in the case the versions are different the error is right, as you cannot have the same package with different versions in a graph, no matter if it a require or a build require.

Yes, that's true. But that is not the case in our scenario.
Thanks for looking into the problem!

[Mark-Hatch-Bose]

I have ran into this as well, but couldn't reproduce it reliably. Just a note!

[michaelmaguire]

This is biting us too.

[monsdar]

Stumbled over this again today :/
Is this something complex to fix? Any idea why this happens?

[lasote]

Going to try to move this forward or at least conclude something.

[lasote]

Looks it is not easy to solve, in the current algorithm, the alias is not "resolved" because another "CA" package has been already used as a transitive consumer of "CC". Resolving that alias in the algorithm might have performance implications in other cases. We need to take a closer look but not easy patch, sorry.

[memsharded]

I am proposing a PR #6236 for this issue. Might not solve all corner cases, but maybe it is not very risky, as it has been conditioned to already having a conflict. Lets see if we can make this into Conan 1.22

[memsharded]

Hi all!

This has been merged in develop, so it is available in https://test.pypi.org/. Will be released in 1.22, but if you could please give it a try, would be very useful.

Thanks @fourbft @monsdar @michaelmaguire @Mark-Hatch-Bose !

[Lizabeth-Roberts-Bose]

Hi @memsharded

I have been testing this fix on two different systems with different environments and it seems that the original issue has been fixed, but it has revealed another potential defect. I am no longer getting the error mentioned above but now instead I am getting the following error

WARN: PkgB/2.0.0@user/channel: requirement PkgA/[>=0.0.1-0, include_prereleases=True]@user/alias_to_channel overridden by PkgC/1.0.0@user/channel to PkgA/1.0.0@user/alias_to_channel 
ERROR: PkgB/2.0.0@user/channel: Incompatible requirements obtained in different evaluations of 'requirements'
    Previous requirements: [PkgA/1.0.0@user/channel]
    New requirements: [PkgA/1.0.0@user/alias_to_channel]

It appears that in the evaluations of downstream requirements it is not resolving the alias correctly some of the time. This error is occurring for me maybe 25% of the time. Perhaps there is some sort of race condition somewhere? Where it lists the new requirements above, it is listing the alias instead of the actual channel which is the reason for the failure. I believe that here is where it it supposed to resolve the alias

Some additional info about what I am trying to do that may help to debug.

1. I am doing multiple installs for different profiles, one after another, meaning the environment is not cleaned before each install and files such as conan.lock and conanbuildinfo.txt are still around for the next install. Perhaps this is causing problems?
2. Depending on the profile, I am installing slightly different build_requires and requirements.
3. At the time of install I am dynamically resolving and generating a list of hard coded versions for some of our requirements rather than using version ranges (this is required for my use case), but this means I am also mixing static versions for some dependencies while using version ranges for others. I am not sure if this would cause any problems but I thought it worth mentioning.

[fourbft]

Hi @memsharded,
sorry for the late reply.Can't unfortunately reproduce the original case where we stumbled over the problem and in the meantime we have resolved this issue by making all requirements either build_requires or requires everywhere, but I can confirm, that Conan version 1.22.0-dev1578476350 solves the problem in my test cases for this issue.
But then, we are not using aliases to channels as mentioned in the post by @Daniel-Roberts-Bose above.