[question] combination of several conan configurations

[dannera]

What is your question?

In our company we use conan across many different independent projects. Each project has its own remote repositories and specific profiles. However most projects use the same tools (e.g. compilers, cmake, etc) that are provided on a central remote and are built with common profiles.

We are looking for a way to provide the common remotes and profiles in one core conan config, while at the same time the projects can maintain their own profiles, remotes or extensions in their conan config. The projects config shall always be based on the core config.

Is there a recommended approach for this usecase of working with several conan configs?

Our initial idea was to combine the different configs by simply installing them one after the other, but the remotes.json gets overwritten. To fix this we consider creating a custom command "config-extend" that deals with this case.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[AbrilRBS]

Hi @dannera thanks for your question. We have previously tried to implement support for appending to the remotes.json file, but unfortunately supporting such a use-case is not planned right now. See here for context as to why it didn't pan out and what our recommendation currently is.

Note that profiles from multiple conan config install calls are able to coexist, as long as they are uniquely named and don't overwrite eachother

[memsharded]

As a side hint, Conan got now the conan config install-pkg (https://docs.conan.io/2/reference/commands/config.html#conan-config-install-pkg) to install configuration from Conan packages, so maybe it could be convenient to generate the different projects configuration "server side" automatically by merging the configs from the different sources with your logic (the same you would do in the client side custom command) and put it in Conan packages per-project. That means, making the "maintainer/build-engineer" side a bit more complex, but the rest of the team/developers side a bit simpler, having to install only 1 configuration. You might also automate this task of creating configs and uploading them with a custom command.

The only issue that this might have is the first initial definition of one of your remotes to retrieve the initial configuration packages.

[dannera]

Thanks for the ideas. Finally I tried the approach with conan config install-pkg, but getting the initial remote of the config is a tricky chicken and egg problem. Therefore it would be very usefull to hand over the initial remote to the conan config install-pkg command: e.g. conan config install-pkg -r <remote-url>.

My workaround for the moment is to provide the compressed conan package on a public remote, so that it can be installed via conan config install <url> -t url

[memsharded]

Therefore it would be very usefull to hand over the initial remote to the conan config install-pkg command: e.g. conan config install-pkg -r .

Thanks for the suggestion, I agree there is a bit of chicken-and-egg problem, and something like this could help a bit. We will give this a try, see if possible.

[memsharded]

Hi @dannera

We have added a conan config install-pkg --url argument that allows to bootstrap a package-based configuration install from a remote not added yet to Conan. It will be in next Conan 2.8, tanks for your feedback!