Feature/compatible ids

[memsharded]

Changelog: Feature: New binary compatibility mode. Recipes can define in their package_id() an ordered list of binary package variants that would be binary compatible with the default one. These variants will be checked in order if the main package ID is not found (missing), and the first one will be installed and used.
Docs: conan-io/docs#1468

Closes #5839

This mechanism can be used:

• To define fallback compatible binaries in case of missing ones, but use the closest or most modern one to the defined package ID.
• To model things like the Intel compiler compatibility with other compilers (gcc, MSVC).

Maybe this feature can be tested for the Intel-Others compilers issue before releasing it.

[jgsogo]

A priori I think this is a nice addition, I will review it after #5836 changes are taken into account (merge develop?). At first sight, just a comment:

Would you consider an additional method?

def package_compatible_ids(self):
    for info in ...:
        self.compatible_ids.append(info)

This way, this method will only be invoked if the true-ID fails (and probably if there is an opt-in/out activated/deactivated). And probably it results in a cleaner recipe.

[memsharded]

Merged develop, and yes, I think that might be a good idea, I will try it.

[memsharded]

Status update:

• Not using a new method, I tried it, but the logic for the new behavior remains in package_id(). Moving it later to a new method is doable, while the opposite is difficult. Also, this guarantees that the logic runs at package creation time too, so it can detect errors much earlier.
• New syntax to add compatible configurations, please check.
• Validation of settings and options
• New tests covering options too, and validation errors
• New information messages for errors and informing about compatible binaries usage.

[memsharded]

@danimtb it is necessary to test this feature for a flat Intel compiler model. Please make a PoC of it.

[jgsogo]

I really think this feature adds a lot of value, I only have one request I've commented below.

---

I'm also thinking about the compatible_packages member that we could make private. It would require adding the CompatiblePackage to the conanfile in the ctor:

class CompatiblePackage(object):

    def __init__(self, conanfile):
        ...
        self._conanfile.compatible_packages.append(self)

and then we won't need the append in the package_id method:

def package_id(self):
    for optimized in range(int(self.options.optimized), 0, -1):
        compatible_pkg = CompatiblePackage(self)
        compatible_pkg.options.optimized = optimized
        # self.compatible_packages.append(compatible_pkg)

But I haven't decided yet if it is better to have or not that last line. wdyt?

[memsharded]

But I haven't decided yet if it is better to have or not that last line. wdyt?

Oh, yes, I like it. I prefer that we hide the append, less lines, less interface surface. I am going to add it.

[danimtb]

Linking here the POC with the Intel compiler: https://github.com/memsharded/conan/compare/feature/compatible_ids...danimtb:feature/5590_compatible_ids?expand=1

[lasote]

Do the docs

[lasote]

As we discussed I don't like the interface, a user declaring a CompatiblePackage(self) is registering something magically, and the user is not accustomed to that, is accustomed to doing CMake(self) and happening nothing. But anyway, is your call.

[memsharded]

On a second (third, fourth?) thought, I think yes it might be better to have self.compatible_packages.append(compatible_pkg) explicitly. What do you think @jgsogo, I have assigned you a review to get your final thoughts about it, you were not even sure when you suggested it.

[jgsogo]

I agree with the previous comments and I'd go for a more explicit approach. If there is no get-function, I think it is better to add the self.compatible_packages.append(...), otherwise it looks like there is a dangling object around and the user won't know what to do with it.

It requires documenting and exposing more interface (the compatible_packages member and the append method), but I think it will be easier for the user.

[memsharded]

Please check latest changes, I have added checking the final settings/options in the package_info() method, which seems to make sense.

[jgsogo]

Great! Really needed to propagate the actual settings and options to be used by the package_info() function.