Automatic actions/xlets dependency installation

[schorschii]

I really like the new downloadable Nemo actions introduced with Mint 21.3. However, I have concerns about the usability. Nearly all of them require specific packages installed to work properly. I doubt that users will read the corresponding readme.md. They rather install it and then wonder why it's not working. Wouldn't it be possible to add a new dependencies section to the spice's metadata.json where to put the necessary package names in? The xlet manager could then check and ask to install it.

This PR is a quick proof of concept to get your opinion. Feel free to push improvements on this branch if you like.

CC @rcalixte

[anaximeno]

I was thinking about this also while testing in the last few days and didn't report an issue because the repo was already archived, but I agree that this is necessary.

Instead of directly installing the dependencies, we should ask the user for permission before installing and then install or alert them about missing dependencies when they click to add the action to the context menus. The latter might be better if there are more complex dependencies that can't be easily installed, also, we won't have to adapt for the different package managers of the different distributions (since Cinnamon is used in more distros).

[rcalixte]

I'm still processing thoughts here while also waiting for others to chime in but at the minimum, this should use PackageKit as it is more distro-independent than apt. I'm mixed on the dependencies being re-defined where Actions already have them as a source of truth but I can see it in the metadata for other xlets. We should implement any detection for dependencies to account for no reduplication for Actions. I also agree with @anaximeno that the user experience should be deciding over whether they would like to install any additional packages or not via some sort of prompt. These are my initial thoughts for now but thanks for the proposal!

[schorschii]

Thanks for both of your feedback. I made a first proposal with PackageKit (code inspired by the Mintdrivers application).

[schorschii]

@rcalixte The .nemo_action file is not necessarily the truth when it comes to required packages. Have a look at my Convert MSG action. It needs the msgconvert command in $PATH but the providing package is libemail-outlook-message-perl.

[rcalixte]

@rcalixte The .nemo_action file is not necessarily the truth when it comes to required packages. Have a look at my Convert MSG action. It needs the msgconvert command in $PATH but the providing package is libemail-outlook-message-perl.

I see what you mean. The challenge becomes defining this across distributions where package names are not consistent. It may be simpler to check the $PATH for the binary since that is something that should be the same across distributions but there are tons of Spices that already do this independently. The Dependency field in Actions works like this for this reason.

[lestcape]

@schorschii I think your dependencies session of the metadata.json should be provided per distribution name, because the required packages could be different per distributions.

"dependencies": ["packagename1", "packagename2", ..., "packagenameN"], 

should be:

"dependencies": {
   "mint":   ["packagename1", "packagename2", ..., "packagenameN"],
   "ubuntu":   ["packagename1", "packagename2", ..., "packagenameN"],
   "arch":   ["packagename1", "packagename2", ..., "packagenameN"],
}

Then you should check if you are on Mint and apply your Mint default solution and in other distros, just check for the existence of a file that takes care of installing the dependencies per distro (see the example).

Also, I think you should make sure whether or not it is correct to install Mint packages using package kit directly, because this can possibly bypass some MintUpdate regulations. So probably in Mint the package should be installed using the specific Mint's requirements and in other distributions it should be left to other distributions to implement how the packages are installed there and not do it in their name.

As an example: See how the cinnamon menu decided if it can uninstall or not apps:
https://github.com/linuxmint/cinnamon/blob/master/files/usr/share/cinnamon/applets/menu%40cinnamon.org/applet.js#L1267

What it do is check for the existence of a file called cinnamon-remove-application that need to be provided by the distribution, not by cinnamon. That way the uninstallation is delegated to the distro.

I believe that your solution in principle, should be the same or similar to how the problem was resolved there.