[feature] 💡Generator for workspaces

[ytimenkov]

From workspace discussions in https://github.com/conan-io/tribe/pull/19 was thinking that major setback of workspaces is a lack of custom generator.

Now with new-style generators and python requirements I think it would be fairly easy to add such support to workspaces:

1. Add python_requires field to workspace definition.
2. Add generators field in same form as python_requires_extend: <pkg-name>.<ClassName>. Then conan can just go through that list, instantiate generator with workspace definition and then call generate() method (or generate_workspace).

This should be enough to start experimenting more.

[solvingj]

The existing implementation, assumptions, and goals of the feature called "workspaces" have proven to lead to too many unfortunate outcomes. There are different tickets and discussions around various parts of it. The result is that the Conan team is looking to dramatically re-design it for Conan 2.0. I suggest you hold of an any experimentation until after a new vision and strategy for workspaces is outlined in the coming months.

Of note, indeed one of the major unacceptable implications was the need to create and maintain new and separate "workspace-specific" generators for each build system. Any future design of workspaces must work with the existing generator implementations.

[ytimenkov]

Well, would be interesting to see the outcome.

But I'm not sure I agree with

Of note, indeed one of the major unacceptable implications was the need to create and maintain new and separate "workspace-specific" generators for each build system. Any future design of workspaces must work with the existing generator implementations.

At least how I see it is that Conan allows to easily split monoliths into components and pull them together later (so each component can have own cadence and shared easily instead of copying into each monolith) - e.g. utility, client API library, server daemon. All good until one needs to make a major change which involves active development of multiple such components.

At this point it is really helpful to have all such components being pulled back into that monolith to have proper incremental builds (when build system can track all dependencies from files to final targets all the way) and code navigation in IDE. For example "go to definition" in one component should find implementation in another one. Same for other refactorings (like "rename").

Honestly I personally fail to see how this can work across different build systems and with common generators.

True that ability to seamlessly integrate binaries produced by different build systems is a killer feature of Conan, but having this constraint for development workflow would be too much imho.

Of course having something like CMake's ExternalProject module is an option to build a subproject with a different tool, but having this as the only option for workspace would probably not work for real integration in IDE.

But I would really like to see what you'll come up with 👍