Allow desktop IDE preferences (e.g. plugins) to be set via the .gitpod.yml

[loujaybee]

Currently, the user can set their preferences for which IDE to open a global/user level, this issue/feature request is to track the ability to set IDE preferences via .gitpod.yml, e.g. extensions.

Related to: #6602

Related discussion in Discord

Related JetBrains issue: https://youtrack.jetbrains.com/issue/CWM-4987

[csweichel]

Which one would take preference? User or .gitpod.yml setting?

[svenefftinge]

I don't think the configuration for what IDE I want to use is something that should be configured on the repo (gitpod.yml) but is rather a user preference.

[gtsiolis]

... but is rather a user preference.

+1. See also relevant past discussion in #4258.

[titimoby]

I use Gitpod for the ability to have really various environment.
So when I start a python project, I'm more willing to use PyCharm but if I work on some of my Go or TinyGo project, I will prefer Goland.
And as I also need to work on the main product, I need Kotlin/Java in IntelliJ.

This is especially true if a developer is working at day with IntelliJ but wants to collaborate to Open source project based on another IDE and language

[gtsiolis]

Thanks for the feedback, @titimoby! 🧡

thought: Relying on .gitpod.yml for selecting the editor sounds interesting but could easily break user experience as editor options can change in the long run, editors can be deprecated, self hosted instances could run earlier versions which don't necessarily support more editors, and more.

suggestion: Instead, what we could do is make this a project[1][2] setting which would also resolve the issue you describe in #6706 (comment) as project settings would always rely on the available options per instance.

risk: Things to consider if we make this a project setting include having a fallback when an editor is replaced or removed.

thought: If we go down this road, nudging users to enable desktop IDEs or switch to a specific editor like PyCharm could be also interesting.

[loujaybee]

Disclaimer: This issue was also/mainly about extensions / customisations for the editor. I put together the issue quite hastily, however the above discussion is also quite interesting! 🙏 I was referring mostly to having features/integrations as we do in the current vscode namespace in our YAML and .gitpod.yml, and/or features like opening previews. This also relates to the open issue that we have to support gitpod some IDE actions via gitpod CLI where necessary: #6506

With regards to:

Relying on .gitpod.yml for selecting the editor

It's worth linking to this Discord poll where I was asking for some feedback on how IDE's should be configured e.g per-project etc, including this comment:

I want to provide a happy path for users of my workspace/project but also enable them to customize and configure the default workspace to their needs.

Which seems similar to the sentiment/request @titimoby is describing above [1]

Which I think is a nice summary/request, e.g. to have happy-path configurations for IDE's on a per-project basis, but whilst allowing the user to over-ride configurations with their own personal preferences. Discussion about configurations per-project/per-user also relate to roadmap items like having dotfiles for users: https://github.com/gitpod-io/roadmap/issues/21

Yeah this is true. I'm really looking for a terrible place where on a single repo, developers can use VSCode locally, or remotely, and IntelliJ locally, and remotely. You know, like in a non web based development environment where people pick their favourite IDE 😉 (source: a similar discussion in Discord)

Finally, regarding:

suggestion: Instead, what we could do is make this a project[1][2] setting which would also resolve the issue you describe in #6706 (comment) as project settings would always rely on the available options per instance.

Project settings are an interesting point @gtsiolis 👀 I'll CC @jldec for his input on that point as well.

[buggtb]

Personally I'd like a flexible solution, committing things to .gitpod.yml probably doesn't help.

Take this type of workflow, which I'll actually be going through this next couple of weeks:

Start of Week 1, work from home. Use Intellij Desktop & Remote Gitpod Workspace
End of Week 1, work from boat. Use IntelliJ Projector inside Remote Gitpod Workspace on a Chromebook to save my batteries when on the boat
Start of Week 2. Hotel & Airport. Use IntelliJ Desktop & Remote Gitpod Workspace because of crappy airport wifi.
Middle of Week 2. Use IntelliJ Desktop and checkout code locally because I'm on a plane!
End of Week 2. Use IntelliJ Projector inside Remote Gitpod as I'll be on the move and would rather save my batteries.
Week 3. Back in an office. IntelliJ Desktop and Remote Gitpod Workspace.

This is the type of flexibility Gitpod could well bring, and I think judging by the comments on Discord, what people are looking for when they've swung by for the intellij beta.

So in an ideal world, you could select whether you want desktop or web based when the workspace was launching, a bit like when it gives you the selection for what desktop IDE you want to use, but adding the web options as well.

What you may end up with though, are different commands being run depending on whether you're running a web ide (bringing in your configs and stuff) or a desktop IDE(where its already on your local machine).

[ghost]

Personally, I was thinking of something similar to Windows' open with dialog + overridable per project config + per user config.

You could open the workspace with vscode, jetbrains, your config or the project config.

[0Grit]

Note: This is a rats nets of a concept that I'd personally love to avoid thinking about.
I'm not a pragmatist developer though, I am an early adopter. And this could be important for gitpod to cross reach the majority of the market. At the same time I wonder if it can wait until after you have a foothold in a niche market.

In my opinion the success of VSCode lies in the standards based approach that was taken.
Language server, MS Debug Adapter Protocol, there are probably others I'm unaware of.

Did MS create a standard for IDE configuration?
Without a standard like that I'd fear for Giptod's ability to maintain various IDE configurations.

My main requirement for a feature like this is that somewhere somehow the "Project settings" which end up being separate from the workspace repository will be version controlled, and exist in human readable format.

I am envisioning a concept where I point gitpod to a git repository which contains my global workspace preferences. And each gitpod project can also point to a git repository containing project specific preferences.
Abstracting this paradigm from the pragmatist user though would require managing the git repositories for them. I think this sounds pretty cool, but I'm not going to put much more thought into it. I don't need it yet.

[akosyakov]

I don't think it is feasible and worth doing conceptually. We will need to customize each editor to respect settings from .gitpod.yml which is rather hard task in first place and will require maintenance. I would prefer clean separation of concerns:

• .gitpoy.yml for workspace specific configurations, tasks, ports, and so on
• editor specific configurations via settings files of corresponding editors.

[loujaybee]

Thanks for the feedback, all 🙏

I think some of these comments also apply to: #6602

[loujaybee]

Closing, as duplicate with other work #9445