[question] Define aliases that depends on settings and options

It possible to define alias packages that use the settings and options to define the target packages?

My first approach, would be, for being able to get access to the settings and options when Conan is loading the recipe, to re-define the attribute alias as a property using python decorator @property. By doing this, the self context is accessible. Here the recipe for the alias.

from conans import ConanFile
from conans.errors import ConanInvalidConfiguration

class BoostAliasConan(ConanFile):
    name = 'boost'
    version = 'latest'   
    revision_mode = 'hash'

    settings = 'os', 'compiler'

    options = {
        'shared': [True, False],
    }
    default_options = {
        'shared': True,
    }

    @property
    def alias(self):
        if self.settings.os == 'Windows':
            if self.options.shared:
                boost_version = '1.57.0'
            else:
                boost_version = '1.63.0'
        elif self.settings.os == 'Linux':
            boost_version = '1.72.0'
        else:
            raise ConanInvalidConfiguration('This configuration is not supported')

        return f'boost/{boost_version}@user/stable'

When using the alias package boost/latest@user/stable without specifying any option, the alias resolution is fine. But specifying option shared=False on install, then the alias recipe still will have the default value set. this results in getting boost version 1.57.0 instead of 1.63.0.

What would be the right way to define such aliases?

• I’ve read the CONTRIBUTING guide.

[memsharded]

To follow up: it is not possible to use settings and options in alias to decide dynamically, and it would be quite complicated to implement, adding too much extra complexity when we are trying to simplify the alias logic.

In any case, it is possible to define a “proxy” recipe that implements the logic, (and can remove the variance of packages removing settings and options in package_id().) That would be a regular recipe, not an alias, and will be represented in the dependency graph, but I don’t see a reason this won’t work.

I’d say the question is responded and can be closed, if that approach doesn’t work, we could discuss why and what are the alternatives, but at the moment I am closing this because because it doesn’t seem something possible to implement reasonably.

[memsharded]

I am afraid that such is some bad behavior, possibly because some internal caching in the legacy requires = "foo/latest" syntax. The new explicit alias syntax approved by the Tribe for 2.0 (and already available at least since 1.39), will fail exactly in this step, because the settings and options are not initialized, this test proves it:

def test_alias_settings():
    c = TestClient()
    c.save({"conanfile.py": GenConanfile()})
    c.run("create . foo/1.0@")
    c.save({"conanfile.py": textwrap.dedent("""
        from conans import ConanFile

        class FooConan(ConanFile):
            settings = "os"
            options = { "shared": [True, False] }
            default_options = { "shared": False }

            @property
            def alias(self):
                self.output.info("os: {}".format(self.settings.os))
                print("shared: {}".format(self.options.shared))
                return 'foo/1.0@'
        """)})
    c.run("export . foo/latest@")

    # Legacy syntax, might load settings/options, incorrectly
    c.save({"conanfile.py": GenConanfile().with_requires("foo/latest")})
    c.run("install .")
    # New syntax will raise
    c.save({"conanfile.py": GenConanfile().with_requires("foo/(latest)")})
    c.run("install .", assert_error=True)
    assert "Alias definition error in foo/latest" in c.out