Lightweight workspaces aka Temporary editables

[ezaiakinsc]

To help us debug your issue please explain:

• I've read the CONTRIBUTING guide.
• I've specified the Conan version, operating system version and any tool that can be relevant.
• I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

Documentation states, that workspaces are similar to editables, just not system-wide ones. Unfortunately, it is not exactly correct: current workspaces do require a lot of additional parameters like roots etc, which are not like non-system-wide editables, and prevents such a workflow (for example, by demanding relative path between sources and build directory, which is not always possible - say, C: and D: drives on Windows).

We are suggesting new simple feature: optional argument for conan install command - filename of the workspace file, that contains ONLY list of editables (or other fields are ignored, whatever, you choose best). If this parameter is set, Conan performs "editable add" for each element of list in-memory, without changing global configuration, and then performs conan install action, as usual (works perfecly with custom generators).

One can see, we are suggesting literally "editables, just not system-wide ones", for us that would be ideal (also I believe I saw other teams mentioned in issues it will be good for their workflow too).

This feature is finite (no need to iterate syntax etc as long as performs same as "editable add" but in memory), and simple to implement (we prototyped it in local fork in few hours, and we are not experts in Conan sources at all).

Please consider implementing "lightweight workspaces/temporary editables" in nearest releases, if possible.

[jgsogo]

Yes, it could be a nice feature and really easy to implement.

---

We opted for the workspaces way instead of adding more features around editables because we think that editables is not the final answer from the developer point of view. The reason why you use editable packages it is because you want to modify sources from all of them, with editables you need to open each of them individually (I'm thinking about VS) while the workspace solution should offer you the opportunity to open them all into a single solution, so just one IDE window (again thinking about VS).

We/I may be wrong about previous assumptions, so any feedback you can provide is more than welcome.

[ezaiakinsc]

Hi @jgsogo,

You are totally right, surely, workspaces are designed to cooperate with OSS cmake/etc generators and make them powerful in scenarios with MSVC-alike multi-projects.

However, for custom generators workspaces or for people using, say, Android Studio instead of Microsoft infrastructure, workspaces are not very helpful. Comparing to editables, workspaces are imposing additional limitations, for example, inability to use unrelated build directories (showstopper for us) or inability to use conanfile.txt as root element.

With our custom generators and Conan editables, we are already able to generate multi-project configuration, editing and compiling them all in one solution, exactly like you described. With our custom NLO generators no need to edit/build them separately, it is limitation of the OSS cmake generator, not limitation of editables as concept. We have already described our use case here: #4878 - it actually perfectly works with editables, seamlessly delivering dependencies as sources or as binaries, depending purely on editables configuration.

Please consider implementing "lightweight workspaces/temporary editables" in nearest releases, workspaces are unusable for us, at least since 2018. As result, we had to cut workspaces support from our system completely, and developers are irritated by everyday needs to add/remove editables just to invoke conan install.

If we will have "temporary editables", we'll need no workspaces at all, so I will be able to close workspace-related issue #4801 as well.

[jgsogo]

I understand your pain, and it would be nice to have this feature. Right now for the common use case, the lightweight workspaces is not something very useful because you should provide through the command line the layouts and the references, so it is too much information for a CLI command. Maybe for your use-case you just need the references, but if we implement it, we should add the ability to specify everything needed.

There are two other things that may affect this development:

• We are not sure about current workspace implementation (that's the reason the are experimental still, and why I have proposed a different approach in [workspace] [POC] Handle all the packages involved in a WS (editables and dependents) #5314). In this proposal, layouts for the editable packages are removed.
• We are investigating a different approach to layouts (and editables) that may simplify local commands (now it is somehow confusing the source_folder, build_folder,... for the local workflow). The idea is that maybe layouts are no longer necessary. I think we will be able to have a preliminary POC or some idea about this later this week.

As you can see, both proposals are targetting layouts, so they are no longer necessary or not as an external file. If we don't need layouts for editables, then the command line you are demanding is just a list of references and it would be an easy way to create a temporary WS.

---

Until then, maybe you just need a shell script that makes this for you: wrap the conan install ... call between several conan editable add and conan editable remove for a list of references you provide to your script.

[kenfred]

This is related to some of the discussions in #5762, so linking here. I'm also looking forward to the workspace/editable redesign. @jgsogo is the approach in #5314 the current direction? Where can we find out about the proposed design?

[memsharded]

Ticket #15992 is gathering the information for workspaces in Conan 2, lets follow up there, I am closing this ticket.