Extend [system_tools] to [system_packages]

[KerstinKeller]

What is your suggestion?

As of now, we can use profiles to describe our different build environments. Conan also has a possible to integrate with system package managers to resolve dependencies, which may be present in a base system.
This is nice, but a lot of times, especially in embedded usecases the whole system setup is a bit more subtle. So why don't take the [system_tools] approach a bit further, and extend it to [system_packages].

Often, when dealing with embedded devices, they come with an SDK, which I will refer to as "the platform".
A typical usecase would be that I want to build my (existing) software stack for such a new platform.
This means that for this concept of a platform (which could, but musn't be a setting - maybe an OS subsetting) - I need to be able to proxy Conan recipes, or tell Conan that there is a set of dependencies, which it shouldn't resolve. Ideally, I don't want to touch existing recipes in the process, but opt-in into the whole thing.
What would be even better, if I could provide a fixed version for a given library, for a given platform, and Conan would at least tell me if version checks are satisfied, or the platform versions are conflicting in any places.

--------------------------
  Platform X

--------------------------
  Platform Y
  - libA == 1.0

--------------------------
  Platform Z
  - libA == 1.1
  - libB == 1.0

So let's see the recipes:
libA & libB don't have any dependencies, they are available in Version 1.0 and 1.1
App would be:

def requirements():
  self.requires("libA/[>=1.0]@")
  self.requires("libB/[>=1.0]@")

So now I would like to build App for Platform X, Y and Z.
For X, conan would resolve libA=1.1, libB=1.1, build those and also build App.
For Y, conan would see libA is in the platform. So it would resolve libB=1.1, build it, and then build App, using libB from Conan and libA from the platform.
For Z, both libA and libB are available in the platform, so Conan can go ahead, App would resolve as if it had no dependencies, and App could build entirely against the platform.

Even better if I had

---------------------------
  Platform U
  - libA == 0.9

Conan would tell me, that App cannot be build, because requirement libA/[>=1.0] is not fulfilled by the platform.

Like with [system_tools], it could be modeled in the profile.

[settings]
os=Linux
os.distribution=platformZ
arch=x86_64
compiler=gcc
compiler.version=9
compiler.libcxx=libstdc++11
compiler.cppstd=gnu11

[system_packages]
libA=1.1
libB=1.0

If you are targeting only Windows & Ubuntu, something like this might not be a big of a deal. (Although of today our recipes are not very nice looking, trying just to model that for the different Ubuntu platfoms). But if you have a software stack, which you want to build on top of a bunch of different embedded systems, it is a real usecase - and a real pain, something that Conan does not handle well yet.
So curious to hear what you think!

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[AbrilRBS]

Hi @KerstinKeller, thanks a lot for your request and the reasonale behind it, it helps a lot for learning the needs of users :)

The great news is that this is something that we have already worked on in #14871! Work was slowed down for it as we prioritized other aspects of the client, but we'll keep your request in mind for it

[KerstinKeller]

Hi, thanks for linking the work. This sounds really promising. Please keep me in the loop, also if you need more feedback.

[KerstinKeller]

Closing in favor of #14566.