Provide plug-ins recommendations

[benoitf]

Is your enhancement related to a problem? Please describe.

When user starts with a repository without devfile, they don't have any plug-ins enabled.
For example using spring petclinic, no java intellisense is provided.

use cases are the following:

• Provide featured plug-ins on fresh repositories without devfiles (no plug-ins) based on what are the featured plug-ins in plug-in registry.
• Suggest/Recommend plug-ins when opening files based on what is stored in che plugin-registry
• Suggest/Recommend plug-ins when opening projects that have .vscode/extensions.json file (and matching plug-ins available from the plug-in registry)
• Suggest/Recommend plug-ins when opening .code-workspace files that have extensions/recommandations field (and matching plug-ins available from the plug-in registry)

Describe the solution you'd like

Featured plug-ins are 'manually selected' plug-ins that are promoted from the plug-in registry.
All other recommendations are automatically generated from plug-in registry content.

Acceptance Criteria

• If the user accepts the recommendations the workspace should be reloaded.

• If the workspace already includes the recommended extensions the user won't be prompted.

• If the user ignores the recommended extensions he shouldn't be asked again when the workspace is restarted.

• When accepting recommendations user should be prompted if files .vscode/extensions.json should not .che/che-theia-plugins.yaml be created/edited or not.

• If the user updates .vscode/extensions.json or .che/che-theia-plugins.yaml he should be asked if he wants to include the extensions and reload the workspace.

[gattytto]

• Provide featured plug-ins on fresh repositories without devfiles (no plug-ins) based on what are the featured plug-ins in plug-in registry.
• Suggest/Recommend plug-ins when opening files based on what is stored in che plugin-registry

it would be nice to have a "notes" field in plugins meta.yaml, so one can add extra notes for different versions of the same plugin/extensions-combination. example: "you are using the haskell debug-adapter, but it will not be activated until you open a .hs (or others haskell) file". Or "haskell stack/bazel build is required for peeking/going to a definition in code files, click to run or it will when you open a haskell code file".
So the user can be warned of inactive extensions and how to activate them, or how to feed artifact caches before opening code files.

for the extension-based recommendations there's this field in package.json for vsix extensions:

"contributes": {
    "languages": [
      {
        "id": "haskell",
        "aliases": [
          "Haskell",
          "haskell"
        ],
        "extensions": [
          ".hs"
        ]
      }

[benoitf]

hello @gattytto, yes this fragment of vsix package.json will be used to make generic recommendations
But I'm unsure to get the idea about the notes field of more precisely the use-case you're describing on a plug-in there but not activated.
Could you add more details and how VS Code is behaving on this specific use-case ?
Most of stuff is performed by doing lazy loading: we activate extensions only if user triggers a specific command or if a file is in present in a workspace.
I'm afraid that we may end in tons of 'notes' if I open a workspace like:
you can open java files, you can open yaml files, you have the debugger, etc
I suppose viewing plug-ins list could be enriched or we need a dedicated UI, because too many notes will flood the user ?

[ericwill]

@gattytto I think what you're describing might be better suited for the README of the sample project, that way it can be formatted in a clear way and users can always reference it.

[l0rd]

I have added some "Acceptance Criteria" that I had initially included in #18668

[nickboldt]

Target 7.27, but can backport to 7.26.2 if @sympatheticmoose deems it important enough.

[sympatheticmoose]

We'd hoped for this in CRW 2.7 (7.26)

[benoitf]

review is taking too long. it's like in infinite loop

[sympatheticmoose]

@benoitf anything that would help resolve? Maybe a dedicated call/working session?

[tsmaeder]

@benoitf @sympatheticmoose I checked back last Thursday and some changes had not been pushed. Friday was H&H day. Also: not all comments were addressed and a companion docs PR is missing. If that requirement should be waived, let's discuss it.
Currently I'm just waiting for the docs PR and an answer to all questions.
Also, a little ping in the plugins/editors chat helps attract the attention if you urgently need feedback.

[benoitf]

@tsmaeder PR is there for months, no review for a couple of weeks after changes have been made, and 'changes not pushed was fixed in 10mn' so problem is elsewhere.
And AFAIK it's a review by a whole team not by you explicitly.
And it looks like you're doing egg and chicken problem with doc if we reduce the scope at the end.

[tsmaeder]

@benoitf the problem with the PR sitting there is that me personally, I get added as a reviewer "as a code owner" to way more than I could ever review. So I just look at the ones where I kinda know I can meaningfully contribute or where I'm explicitly requested. Reviewing a PR of this size takes at least a couple of hours if you take it seriously, so it's not a side task.
I wasn't aware of this PR until a couple of weeks ago. Since this work is not going through our planning cycle, it's not on our radar until someone puts it there. If your PR just sits gathering dust, maybe ping someone on a different channel?

[tsmaeder]

About the docs PR: I think we need one because of the new preference setting. I wasn't sure about where the key was used: maybe it was documented elsewhere. Seems it's not.

[ericwill]

There are unaddressed comments from @sunix from 28 days ago:

• feat(recommendations): Provide a plug-in for recommendations che-theia#916 (comment)
• feat(recommendations): Provide a plug-in for recommendations che-theia#916 (comment)
• feat(recommendations): Provide a plug-in for recommendations che-theia#916 (comment)

If they aren't blocking concerns then let's discuss or comment in the PR. As for this comment, @sunix please check it again.

[benoitf]

@ericwill I tried to fix the requested changes comment first because if you don't fix the blocking stuff, other comments won't change something

it has been fixed there: eclipse-che/che-theia#916 (review) and no reply since.

so when blocking changes are gone, I may address other comments

[nickboldt]

We'd hoped for this in CRW 2.7 (7.26)

@sympatheticmoose might help to escalate this from "P2" priority to something higher so it floats higher on the auto-backlog. Also setting it to the 7.26 milestone would be a good indicator that this is meant for CRW 2.7

This issue also has no assignee, and is not labelled with a team owner, only the dev-experience area.

[ericwill]

We'd hoped for this in CRW 2.7 (7.26)

In the future, let's discuss these during prioritization and create downstream tickets with appropriate fixVersions. This issue has a milestone of 7.27 and is marked as P2. Apart from a small entry in the 2.7 JIRA epic description, I have no way of knowing that this is a priority item for CRW 2.7.

@ericwill I tried to fix the requested changes comment first because if you don't fix the blocking stuff, other comments won't change something

it has been fixed there: eclipse/che-theia#916 (review) and no reply since.

so when blocking changes are gone, I may address other comments

I can see your point, but leaving comments unaddressed for weeks also gives the impression that the PR isn't being worked on or is low priority. In the future, let's:

• address comments on the PR
• communicate CRW priorities better

and I will make sure reviews are quicker.

[nickboldt]

Maybe it's time to implement an "epic/crw26" label so we can more easily query for issues that PM wants from upstream, and then be able to turn those into JIRAs linked to the CRW epic issue?

Right now there's no way to know if a given Che issue is important for a given CRW release, or to easily query for more than one label.

Because we also can't have more than one milestone per issue (unlike JIRA, which can have multiple affectsVersion and fixVersion values), and we don't currently use a "backport" label, only a backport PR will bear the information that a given issue's solution in 7.27 was also backported to 7.26.x.

So... WDYT about adding these labels and encouraging their consistent use in future?

• backport-requested
• backported
  and
• epic/crw26
• epic/crw27
• ...

[nickboldt]

Sounds like it's too late to get this backported into 7.26.x and CRW 2.7. I've updated the 2.7 & 2.8 epics accordingly.

• https://issues.redhat.com/browse/CRW-1268 2.7
• https://issues.redhat.com/browse/CRW-1566 2.8

[Ohrimenko1988]

I don't observe such functionality on the latest Che
chectl version: chectl/0.0.20210420-next.13d2bcd linux-x64 node-v12.22.1
devfile:

apiVersion: 1.0.0
metadata:
  name: java-maven-vk57v
projects:
  - name: console-java-simple
    source:
      location: 'https://devfile-registry-iokhrime-che.192.168.99.254.nip.io/resources/java-maven-console-java-simple-java1.11.zip'
      type: zip

I created a workspace using mentioned devfile. As you can see it contains only the project definition without any plugins.
After the workspace start I opened it, expanded project and opened the java file. But no prompts were been shown.

[benoitf]

@Ohrimenko1988 this issue has already been done
I've reopened #19610