Show that included plugins and webapps can not be uninstalled

[tkurki]

People try to uninstall for example Freeboard. This only removes any updates of the included plugins, "revealing" the older version that was installed as part of the server.

Since these can not be uninstalled and the result is confusing we should disallow uninstalling them.

[leonardgable]

Hi tkurki,

When you mean that "These cannot be uninstalled" which apps from the apps store are you referring to ? Should the trash icon be disabled when it the plugins cannot be uninstalled ? Is that the case for all plugins or some plugins could be totally removed ?

[tkurki]

The ones that are there when you install the server, without explicitly installing anything from the app store. They are listed in root package.json.

[leonardgable]

We need something indicating the frontend that the plugins is a "default" plugin and hence it cannot be uninstalled

Let me suggest to add another property to the PluginsInformation object in the openAPI such as:

Reference Here

enabledByDefault {Boolean} True|False - indicating whether the plugins comes with signal K packages and then cannot be uninstalled ? enabledByDefault seems more clear to me

(example below)

However we need to specify the list of provided plugins somewhere in a configuration file, any idea ? @tkurki you are more familiar with the project maybe you already have a place in mind for this kind of conf ?

[tkurki]

property to the PluginsInformation Yes. default is pretty vague, I'd go with something more explicit like serverInstalled.

the list of provided plugins See my previous comment: they are included in root package.json

[leonardgable]

I agree serverInstalled seems to be a good option. I will opt for this one. It seems that there is already an env variable indicating the DEFAULTENABLEDPLUGINS. I will base my work on that env variable "list" to then pass this information to the PluginsInformation object and flag them as serverInstalled or not.

Yeah I have seen what you wrote about the packages.json, I'll continue following the code !

[leonardgable]

@tkurki I have been following the code... not easy when not used to the code base. But it seems there is already a flag enabledByDefault on the plugins. This is initialized in the plugin.ts at the core of the app.

The app carries an array app.plugins which encloses the list of plugin used in the app. Someone already made a boolean flag for the plugins enabled by default. I reused the name enabledByDefault because it was already existing. Didn't want to meddle with all the code simply for the variable name. I think it's quite clear, if you think it is necessary we can rename it

It was missing on the response from the request so I added this extra information inside the response body.

I still need to understand how this flag is set and why all these plugins don't have enabledByDefault set to true on the backend at startup. There must be something wrong there :?

[tkurki]

Sorry, enabled by default is different from installed by default. Please check the issue description.

[KEGustafsson]

Generic question about these server installed plugins. Could those be in ./signalk/package.json? In some cases, there might be need to have just minimum set up plugins installed, pure data proxy server use case and in other case all possible plugins. In first case it would be good to have possibility to remove all not needed without limitations.

Could ./signalk/package.json be available at the install phase and it would be installed after the server installation. There would be need to have a step to install plugins from one package.json, not from read-only as it is now.

For docker, this would be easily doable step, but I don't know for bare-metal installation...

[leonardgable]

I am not sure it is clear to me which plugin must be serverInstalled. I see the list in packages.json but how is this list going to evolve with time ? I don't understand what is the long-term strategy behind this list of plugin, some seems to be optional other seem to be a clear dependency for signalK. Did you already have in mind how this needs to be implemented ? Knowing that you are more experimented with this project you must already what would be the best approach

[tkurki]

• serverInstalled plugins/webapps are ones that (1) are in the list retrieved from npm (2) are installed when you run npm install signalk-server meaning in dependencies or optionalDependencies sections of package.json
• "evolve with time" - modules may be added or removed to package.json, why is that a concern if you just use package.json as the source for this data?
• "long term strategy" is that modules whose install may fail on some platforms (mdns, serialport) or are not needed for the core server to function (default webapps and plugins) are optionalDependencies

To me we've already covered how this should be implemented: provide this flag to the UI and hide the remove button. If you need more step by step instructions this task may not be suitable for you.

[leonardgable]

Thank you for your explanation. I understand better the issue now. I believe #1668 must be resolved first because the server does not support bare-metal plugins as you said. It is then very hard to flag them as "serverInstalled".

[tkurki]

No, this can be addressed without 1668.

[leonardgable]

#1675 I can add a flag on the refactor UI and remove the little trash can. However I hadn't understood yet how to identify the default plugins from the frontend. It doesn't seem very clear to me... I have the impression that flagging default app is quite difficult :)