Bundle extensions and language packs with the installer

[krassowski]

Problem

It is not currently very easy to install extensions, and it may be a demanding procedure when it comes to some extensions which require external dependencies. There are functions that users would expect to be present in JupyterLab, but for the code maintenance reasons it was decided that these are not going there. I would love the installer to include a pre-approved version of:

• jupyterlab-git
• jupyterlab-lsp with a language server
• maybe jupyterlab-spellchecker
• other extensions which are judged as essentials for majority of users and pre-approved by the team

Proposed Solution

I think that it would be good to have:

• a "recommended" install option with the three extensions listed above,
• a "full" install option with additional extensions that were vetted but do not seem essential for majority of users (say jupyterlab-latex, or maybe in the future citation manager) available in the bundle to install, but not actually installed by default
• a "minimal" option with just the JupyterLab core

Additionally some installers include language packs as an opt-in; it might be nice to ship the complete language packs in the installer too and let the user choose their language and install the relevant language-pack.

Additional context

This is a common approach for installers of other applications.

The vetting criteria could include being in the right organization, size, security practices, stability over previous versions etc. I would think that we could be a bit more conservative here and stay a minor version behind at times to allow for extra testing before including extensions update in the bundle.

The three extensions proposed above are just examples and I think only jupyterlab-git would be unanimously approved straight away, and it might be a good extension to blaze the trial.

[amit1rrr]

I'd also vote for including jupyterlab-git in the base installation.

I don't know much about Electron packaging but another approach to manage extensions might be - to have a view/panel inside the app which users can use to selectively install whatever extension they want (similar to VSCode or Eclipse extension installers). This approach would remove all the problems that come with statically including extension assets in the installer (extension updates are tied to desktop app updates causing bugfixes etc not reaching users even though they're released in the extension).

Again, I don't know if this is technically feasible with Electron apps but worth exploring. I can imagine backend extensions being tricky to include at runtime. I'd go one step ahead & even say that, if required, it'd be OK to ask extension developers to package their extensions in certain way to be compatible with JupyterLab desktop app.