[feature] hidden requirements

[smoofra]

Hidden requirements

Hidden requirements would be like private requirements for the purpose of info propagation, but like normal requirements
for the purpose of downloading and fetching.

Synopsis

The idea is that bar should be able to depend on baz, but beyond the fact that baz gets downloaded when you require bar, the only things foo should be able to know about baz are the things that bar explicitly propagates. foo can even transitively depend on two different versions of baz without a conflict.

foo/conanfile.py

from conans import ConanFile

class FooConan(ConanFile):
    name = "foo"
    version = "1.0"

    tool_requires = ['bar/1.0', 'fizz/1.0']

    def generate(self):
        print("You should see BAR and FIZZ here, and not BAZ", self.env)

bar/conanfile.py

from conans import ConanFile

class BarConan(ConanFile):
    name = "bar"
    version = "1.0"

    requires = [('baz/1.0', 'hidden')]

    def package_info(self):
        self.env_info.BAR.extend(self.deps_env_info['baz'].vars['BAZ'])

fizz/conanfile.py

from conans import ConanFile

class FizzConan(ConanFile):
    name = "bar"
    version = "1.0"

    requires = [('baz/2.0', 'hidden')]

    def package_info(self):
        self.env_info.FIZZ.extend(self.deps_env_info['baz'].vars['BAZ'])

baz/conanfile.py

from conans import ConanFile

class BazConan(ConanFile):
    name = "baz"
    version = "1.0"

    def package_info(self):
        self.env_info.BAZ.append(self.package_folder)

Use Cases

Packaging

baz could be some finished software for an entirely different platform that needs to be packaged into foo. For example foo could be an application, baz could be some firmware that needs to be installed on a peripheral to run foo. In this case it would be wrong to propagate cpp_info or anything like that out from baz into foo. Instead foo just wants the finished firmware image for baz so it can package it into its own application bundle or installer.

Including multiple versions of a dependency

foo may have some complicated makefile that needs access to multiple versions of a build time tool, such as a cross compiler. In this case, bar can repackage baz under a different name, without needing to physically duplicate the potentially large baz binaries in the repository and user cache.

[smoofra]

• I've read the CONTRIBUTING guide.

[smoofra]

previous discussion here, in which I didn't really understand how private dependencies worked.

[memsharded]

Hi @smoofra

This has already been implemented in Conan 2.0. It was proposed and approved in conan-io/tribe#26, and it has been implemented and released a couple of alpha releases ago. You can already download and test alpha.6 from PyPI.

The requirements have the visible trait, that control whether a dependency is propagated downstream or not, and together with the other traits and the self.dependencies access, they allow full control of of the requirements. Documentation for 2.0 is an ongoing process, please check https://docs.conan.io/en/2.0-alpha/index.html for updates.

I am closing this attached to the 2.0-alpha.6 milestone, looking forward to getting feedback from it.

[smoofra]

@memsharded wow that's awesome, thank you! I'll check it out.