Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local (per project) extensions #14662

Open
trampas opened this issue Dec 21, 2024 · 3 comments
Open

Local (per project) extensions #14662

trampas opened this issue Dec 21, 2024 · 3 comments

Comments

@trampas
Copy link

trampas commented Dec 21, 2024

Here is the problem...
I go to github and find an embedded project, I clone the project to my local drive and the readme.md says "open project in Theia". I open the project in Theia which is great but I can not build the project, use debugger, etc. Specifically I need to install a cross compiler, but not any one the specific one the developers tested project with. This is same for the build tools.

xpack allows me to configure development tools (gcc, make, ninja, etc). Basically xpack allows user to install tools globally or local to the project folder, in a xpacks directory.

So basically after I install xpack (which is a PITA) I can now install the development tools for the project by doing an 'xpm install' as the original developer added package.json to project for this purpose.

Now in Theia I need to install some way to build the project, that is a makefile extension, or cmake extension, etc. So Theia I would have to manually install these, even if they are only used by this project. So why not have an '.theia/extensions.json' which specifies which extensions the original developer had configured to use with the project. Then Theia could install these "local" (per project) extensions in a Theia/ directory on my hard drive and use them from there just like xpack does. Basically the extensions.json could be similar to how
npm and xpm works and install locally.

This would be great for example if the project uses cdt-gdb verses cortex-debug for another project. We do not want the IDE to have both installed and confusing user which to use for debugging.

Another advantage of per project extensions is when you get like me and do development for different vendors. If I am doing TI development with their code composer extension I do not want to looking at the Nordic extension while building TI projects. I also bet TI and Nordic feel the same as a company.

@tsmaeder
Copy link
Contributor

We do have support for this: see .vscoe/extensions.json in the Theia repo. You will get a notification at startup that asks you whether you want to install the recommended extension for the workspace.

@msujew
Copy link
Member

msujew commented Dec 25, 2024

@tsmaeder See also the discussion over at #14661. I believe this issue is specifically about per-workspace plugins that are only installed/active for specific workspaces.

@trampas
Copy link
Author

trampas commented Dec 25, 2024

Yes the idea is that project A is independent of project B on the same computer. Different extensions, build tools, etc.

A lot of developers are now using docker containers, or devcontainers for this. The issue here is the level of effort to get the new guy up and coding. When you think about this level of effort it is why IDEs were created. As such their is value in IDE managing these "development containers" for developers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants