Configurable and distributable toolchains

[DoDoENT]

Conan profiles are a great way of sharing common settings and build requirements in your development team. However, the feature currently does not have enough flexibility, such as enforcing specific compile flags on all packages in the dependency graph. Also, profiles cannot be distributed as a conan package, so different channels must be used to distribute profile to your development team.
The motivation originated from this Github issue comment.

Proposal summary:
Define a special type of conan package (profile-package) that can be used only in conan profiles or pose instead of conan profile, but have the ability to impose settings on the dependency graph and ability to update the settings.yml file.

---

• Upvote 👍 or downvote 👎 to show acceptance or not to the proposal (other reactions will be ignored)
  • Please, use 👀 to acknowledge you've read it, but it doesn't affect your workflow
• Comment and reviews to suggest changes to all (or part) of the proposal.

[memsharded]

Hi @DoDoENT,

Thanks very much for your proposal. Your proposal is a very big one, and we think it contains several different (connected, but partially independent) feature requests. As commented in the Tribe repository readme, this Tribe repo might not be the best place for such feature requests, but they are better suited for https://github.com/conan-io/conan.

For example, I like the idea of doing “conan config install myconfig/1.0@myteam/stable”, to install a given configuration, instead of using a git repo or a zip file in an http server. And I think it is something that sounds doable. Maybe it is something that we want to implement soon. Does it need to wait until Conan 2.0?

Conan 2.0 Tribe discussions should be built on more established experience. As an example, the Python minimum version we are proposing: Python 2.7 is still supported nowadays, but we have solid experience that Python 3.6 is better for Conan, and thus we propose to use it as a minimum and deprecate Python 2.7. Once we take this decision, it will be really hard to revert it back and support Python 2.7 again in Conan 2.X, not to say impossible. There is no way we could deprecate the current way the toolchains can be installed by users, natively and not managed by Conan. Then, the current proposal would be more a feature request than really an architectural new design and decision to integrate with toolchains. We see very interesting features with potential to be valuable for users, but we need to first land them, implement them at least as prototypes, have some real experience, iterate them, and after that we might elevate them to a proposal.

We would suggest then closing this PR and moving it as a dedicated detailed issue to https://github.com/conan-io/conan (or better, a central issue that acts as a centralizer, but then several smaller and dedicated issues where we could focus on the low level design. We will label them accordingly (we might create a “tribe proposal” label), and will also share with the Tribe in our communications channels, so we can still get the feedback and start learning and iterating on them.

[DoDoENT]

Hi @memsharded,

although I agree that something like conan config install myconfig/1.0@myteam/stable is not a big change that requires architectural changes, I would argue that the proposal for "profile-package" actually is.

The reason is that currently, no conan package can impose settings on the dependency graph. It's not possible to create a package that will define compiler or compiler version and impose that on the entire graph. Also, it's not possible to create a package that will update settings.yml, as described in my proposal. I think that the ability to define settings from the package and impose them on the entire graph is something that may require deep architectural changes, as it would require special kind of packages ("profile-package" or "toolchain-packages") that have the ability to do that, but have some restrictions (e.g. you can't have multiple "profile-packages" in your dependency graph - actually those shouldn't even be in the dependency graph, just like currently profiles aren't).

For example, if someone uses an emscripten toolchain with an incorrect profile (i.e. with profile defining gcc compiler or wrong version of clang compiler, or profile defining wrong OS or architecture), nothing will stop them to shoot themselves in the foot by creating wrong packages (e.g. package with static libraries built for emscripten but advertised as windows x86_64).

The idea of the proposal is to define a founding for discussing how such features could be achieved.

If you still think that this is something that should be added as a feature request in main conan repository, I'll be happy to do so.

[DoDoENT]

(I accidentally clicked the close and comment too soon):

There is no way we could deprecate the current way the toolchains can be installed by users, natively and not managed by Conan.

I agree with that, but with this proposal, we could replace profiles with toolchains that are can be managed more easily. There is nothing wrong with auto-generating the toolchain from the automatically detected compiler similarly to how currently profiles are generated.

Furthermore, by replacing profiles with toolchains/profile-packages, there would be no need for questions like minimum VS version.

Then, the current proposal would be more a feature request than really an architectural new design and decision to integrate with toolchains. We see very interesting features with potential to be valuable for users, but we need to first land them, implement them at least as prototypes, have some real experience, iterate them, and after that we might elevate them to a proposal.

I'm not sure if profile-packages could co-exist with current profiles. If they could, then I completely agree: this is a feature request and should be moved to the main conan repository. If not, then we need to discuss here if we could remove support for profiles as they currently are in favour of toolchains.

[Lizabeth-Roberts-Bose]

I very much like this idea. One of the pain points for us is that there isn't an easy off the shelf way to version or track what configuration was used in the creation of a package. While you can look at the settings, options and such of a package after the fact and manually attempt to re create it via conan install <conanfile> -s setting1=blah -s setting2=blah. There is no way to do something like

conan install <conanfile> --profile profile1/<git hash or version>

This would be extremely useful for reproducing builds more easily with the same settings, via a versioned history of the profile that was used during the packages creation

[DoDoENT]

As suggested, I've opened a feature request in main conan GitHub and will close this PR here.