Open l0rd opened 3 years ago
@l0rd Reading the conversation on the PR https://github.com/devfile/api/pull/333 and this opening post, do we want to go ahead and remove plugins from the spec(but keep in the Go source) like the PR intended? Asking since @amisevsk brought up some concerns for the devworkspace-operator and it seemed like the discussion did not have a definitive conclusion 😄
@l0rd Reading the conversation on the PR #333 and this opening post, do we want to go ahead and remove plugins from the spec(but keep in the Go source) like the PR intended?
Correct
This issue is stale because it has been open for 90 days with no activity. Remove stale label or comment or this will be closed in 60 days.
Is your feature request related to a problem? Please describe
We are currently removing plugins from the devfile spec but being able to reference a devfile or a fragment of a devfile (beyond parents that are limited to one) would be valuable.
Che workspaces for example always include the same components (like the IDE and machine-exec) and those components may have long specs. Having to copy/pasting those components in every single devfile makes devfile harder to read and edit. And an update to those component requires an update to every single devfile.
Describe the solution you'd like
ALTERNATIVE 1
Allowing composition rather than inheritance in devfiles. Deprecating
parent
and introducingimports
.ALTERNATIVE 2
Have a dedicated section (
webEditors
) for IDE tooling:Additional context
For the time being Che will use separate files to let users specify the IDE (and its specific preferences and extensions). Separating the IDE components from the rest of the devfile is probably a good idea. But splitting the spec of a workspace into multiple files is not.