Thank you that you rising it.
I think your questions moving us in the direction of the clarification of the role of each API, factory, and workspace.
Here is my vision of that role
- Workspace API. Classical REST Crud which manipulates workspace object + extra methods that manipulate with runtime state of workspace.
The basic idea here is "what you send is what you get".
- Factory API(che7 part) - is a templating API what allow to resolve different variants of URL's into a devfile that is later can be
reused to create a workspace. The idea is here that we start with URL only and we don't have a devfile. After we call Factory API
we don't have a workspace yet, clients have an ability to inject some user interaction
before the final step - creating a workspace with Workspace API.
This API is focused, but not limited to browser-based interaction.
Relay on that. I would say that use-case
https://github.com/eclipse/che/issues/13617#issuecomment-531758905 is better to address in 1) Factory API.
Regarding your concerns:
> I am more inclined towards applying the overrides on
the workspace API though, because that increases the reusability of a
single devfile - the users don't have to have several variants of a
devfile on the filesystem and can create multiple different workspaces
out of it.
I partially agree with you. I think you are referring to chectl and devfile on a local filesystem.
Yes - factory use-case is not reusable here because we already have a devfile.
On another hand, chectl has to provide some interaction with the user to
get something that the user wants to override. And if we want to make it user-friendly,
not just "give me a map of values to override", we need to give some context
about what we asking: git repo, git branch name, etc. Doing all of that
I see no issue for chectl to: read devfile, ask the user about specific values that
he wants to override, change it in runtime devfile representation and then call Workspace API to create a workspace.
