[Feedback] Conan Essentials - `user/channel` advice

[Minimonium]

The course strongly encourages using custom user/channel for packages that were built locally, not from Conan Center. I agree for proprietary recipes or recipes that were written/created out of the CCI so maybe I just misunderstood the advice here.

The issue with the advice is that a new user may think that migrating CCI recipes to company/stable scheme is the way to go for vendoring recipes to a private remote. Which is practically a bad user experience since Conan provides very poor overriding capabilities in its interfaces and the only way to prevent "leaking" of packages through a private remote would be to override all requirements in vendored recipes, which is a poor application of one's effort and time.

My personal advice is to actually preserve the original user/channel if you intent to use the binaries as-if or in-place of CCI created binaries and control the binary origin through the remote list only.

[memsharded]

The advice could be:

• Use yourteam/stable for your own packages
• Use yourteam/stable for variants, forks, anything that involves changing recipes from ConanCenter.
• Keep the packages from ConanCenter without user/channel, if they effectively come from ConanCenter, or maybe even if they are built locally, but without any change at all from the conan-center-index repo

Isn't that basically what the training is recommending? I think that the video says that it is recommended to use youruser/channel for your own packages.

[Minimonium]

Yes, I don't imply that the advice is wrong, I suggest that it could be useful to extend the point in the material a bit since it's fairly brief now. My concern is especially about your third bullet point, which, again, is my personal experience of a good practice, which may contradict with a broader practice.

[solvingj]

To be honest, the second bullet above doesn't even really seem be be thought through.

If you patch and change zlib and call it zlib/x@user/channel, you have to patch every downstream consumer.. transitively. Either with an override or actually update the references where it's used in your graph. And since you're now patching those, you would then want to build those with @user/channel as well (or be inconsistent in the rule, which defeats the point). You end up having to patch some major part of your dependency graph anyway. This also becomes an extreme maintenance burden to support this seemingly novel policy. The advice just doesn't work as intended, and I think we should stop giving it.

There's really only one context where the advice DOES work, and that's for local development, when trying to patch and compare a zlib with the un-patched original. Then I can

• build zlib/x@solvingj/testing in my local cache
• temporarily add override for zlib/x@solvingj/testing to any end-consumers recipes I want to test locally
• once testing is complete, commit the change and remove the temporary local overrides.

The other alternative I can imagine would be for some teams to patch ALL recipes they use from conan-center, and replace all references to use a custom @user/channel. I could even imagine myself doing this. However, I don't think this is guidance we should give.