devfile / api

Kube-native API for cloud development workspaces specification
Apache License 2.0
255 stars 60 forks source link

Plugins replacement #364

Open l0rd opened 3 years ago

l0rd commented 3 years ago

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 introducing imports.

schemaVersion: 3.0.0
imports:
  - id: java-maven
  - id: mysql
  - id: theia-ide
components:
(...)

ALTERNATIVE 2

Have a dedicated section (webEditors) for IDE tooling:

schemaVersion: 2.5.0
parent:
  id: java-maven
components:
(...)
webEditors:
  - id: che-theia-ide
    plugins:
      - id: java
      - id: github-pull-request
    preferences:
      - editor.tabSize: 4
      - editor.insertSpaces: true

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.

maysunfaisal commented 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 commented 3 years ago

@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

github-actions[bot] commented 1 month ago

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.