[feature] revised plug-in model

[SSE4]

in conan 2.0 we have some models for plug-ins (extensions, hooks, whatever you call it) where users can extend built-in functions of the conan without necessity to wait for new release, for instance:

• hooks (conan config install)
• custom generators (python requires)
• custom build helpers (python requires)
• custom settings (conan config install)
• custom profiles (conan config install)
• custom templates e.g. for conan new (conan config install)
• command line extensions (no idea how managed)

although they are good as a building blocks on their own they don't provide unified experience - they managed in different ways.

I mean you can't just install one plug-in for Arduino which will provide everything : generator, build helper, settings, profiles, etc.
more, even if you do install several of such things (e.g. Arduino and QNX plug-ins) you have the problem of latest win - they will just override each other.

we already know e.g. from Elbrus example that to add new platform or new compiler it's usually not enough to just update settings.yml, e.g. you need: to update:

• cppstd management
• compiler flags management in general (things like arch, sysroot, libcxx, etc)
• mapping for CMake build helper/generator (e.g. CMAKE_SYSTEM_NAME, default generator, etc)
• mapping for AutoTools build helper (host/build/target at very least)
• detection of compiler and os/arch
• other checks, like in conanbuildinfo.cmake

it was previously suggested Jinja2 templates could be used to address part of the problems above, e.g. if you allow to install custom template for the CMakeToolchain, you will be able to get the logic you need. still, your new platform may require new sub-settings, thus you will need new code to convert sub-settings into values CMake understand, so it's again about installing new code extending existing helpers, or adding new helpers.

another idea was to use pip to distribute such things, but that was invalidated by the fact many developers don't have a python at all, and use conan from the pyinstaller, so we can't just distribute things as python packages.
(well, there are still ways to distribute them in isolated environment containing all the dependencies and interpreter, but that's off-topic here).

I personally like the model of the Visual Studio extensions: you may install a single plug-in, which will be able to extend everything needed - it may register new context menus, windows, project types, project templates, etc. - whatever you may need, with a single plug-in. this is achieved by providing sane API for the plug-ins and defining all the extensibility points.

so, if I install for instance premake plug-in, I'd like to get (at one shot):

• premake generator
• premake build helper
• -g premake on the command line out of the box

same, if I install Arduino plug-in, I'd like to get (at one shot):

• settings for arduino

• profiles for arduino

• mapping of the settings for CMake/AutoTools and other existing build helpers

• possibly, build helper to build sketch project

• possibly, generator for sketch projects

• I've read the CONTRIBUTING guide.

[solvingj]

This is an excellent concept with a lot of good points. It's true that Conan has numerous modular, disconnected extension points, and no way to create a "pack" of them. It's also true that the visual studio plugins have tremendous power. Many plugins, can and do undermine the stability, usability, and UX of visual studio. They can make visual studio projects proprietary, and impossible to load/build/run without the plugins. They even suffer from plugins tightly coupling projects to specific versions of the plugin. Nonetheless, Microsoft allows them (as do most other IDEs with plugins, and many other platforms with plugins).

I'm not saying that Conan should definitely empower a plugin system which can fundamentally undermine or change Conan's stability, usability, or UX. However, I AM saying we should genuinely consider it.

Of note, people have been making their recipes proprietary with python imports of their own packages long before python_requires was a feature. Vast number of private recipes are proprietary based on Conan settings as well, and custom environment variables. Many recipes won't work at all without specific custom settings in settings.yml, or specific custom environment variables being declared, or without specific PIP packages installed already. This is kind of a "whataboutism", but it's worth considering.

[memsharded]

Conan 2.0 has extended the concept of extensions and added a bunch of them, from profile checker, to binary compatibility, custom commands, etc.