Feature: Add support for local plugin installation

[flooxo]

This PR closes #2252.

Description

The new method uses plugin.UrlDownload to store the local path of the zip file.
First, the corresponding values are read from the plugin.json file. Then it is installed like any other plugin, except that the zip file is not downloaded.

Changes

Add a new method so that plugins can now also be installed locally from a zip file
Example: pm install c:\plugin.zip.

[flooxo]

Open questions

• The icon is not displayed correctly in the installation command because the path from the zip file cannot be used
• How should update recommendations be handled (should it also be possible to use pm update <localPath>, as this is automatically suggested if the plugin is already installed)
• After the installation the zip is always deleted, which may not be desired, how to avoid this?

[jjw24]

I am thinking:

The icon is not displayed correctly in the installation command because the path from the zip file cannot be used

Use a custom icon, or can we load the zip icon?

How should update recommendations be handled (should it also be possible to use pm update , as this is automatically suggested if the plugin is already installed)

Detect if it's local path, think Explorer plugin already has code to detect if it's local/network path. We can reuse it but move it to the SharedCommands folder in the Plugin project.

After the installation the zip is always deleted, which may not be desired, how to avoid this?

Cleaning up the zip file is by design when downloaded from URL. If local/network path is detected, skip this step.

[flooxo]

Use a custom icon, or can we load the zip icon?

The problem with the icon is that the path to the png would be correct, but it has to be unzipped before it can be displayed. For this it would have to be temporary stored. I think the easiest way is to simply display a custom icon

Detect if it's local path, think Explorer plugin already has code to detect if it's local/network path. We can reuse it but move it to the SharedCommands folder in the Plugin project.

Unfortunately I have not found a method in Explorer to detect if it is a local path (currently I use File.Exsits and sometimes Path.GetTempPath() to check if its a local file)
But there is a lot of redundant code in the update, because especially the prompts are always the same for update from a local file, a single update and update all.

Cleaning up the zip file is by design when downloaded from URL. If local/network path is detected, skip this step.

Thanks

[jjw24]

The problem with the icon is that the path to the png would be correct, but it has to be unzipped before it can be displayed. For this it would have to be temporary stored. I think the easiest way is to simply display a custom icon

Yeah that's what I mean, custom icon or just load the icon of the zip file?

[flooxo]

Yes, thanks, I have done that

[flooxo]

Where are the other icons from? Maybe I need to either add attribution (but I don't know where) or use a different icon since this icon uses the "flaticon license" which is free for commercial use but requires attribution

[Garulf]

@onesounds could you please lend a hand with icons?

[jjw24]

Unfortunately I have not found a method in Explorer to detect if it is a local path (currently I use File.Exsits and sometimes Path.GetTempPath() to check if its a local file)
But there is a lot of redundant code in the update, because especially the prompts are always the same for update from a local file, a single update and update all.

@flooxo this is what you need:

Flow.Launcher/Flow.Launcher.Plugin/SharedCommands/FilesFolders.cs

Line 207 in 73f2c3b

public static bool IsLocationPathString(this string querySearchString)

[Garulf]

The new method uses plugin.UrlDownload to store the local path of the zip file. First, the corresponding values are read from the plugin.json file. Then it is installed like any other plugin, except that the zip file is not downloaded.

Could you explain why we need a local path in the plugin's manifest? Shouldn't allowing pm install <local path> be enough?

[flooxo]

The local path is required because when calling InstallOrUpdateAsync it is no longer possible to access the local path as this is not passed anywhere. However, the local path determines whether the plugin must be installed or downloaded first. And also in the case of updating the existing plugin, the local path must be reused to suggest pm update <local path>. If that makes sense :)

[flooxo]

@flooxo this is what you need:

Flow.Launcher/Flow.Launcher.Plugin/SharedCommands/FilesFolders.cs

Line 207 in 73f2c3b

public static bool IsLocationPathString(this string querySearchString)

Thanks! But this function does not check whether the location exists, which is crucial.

[Garulf]

Would it be best to use pm install at the new zip file for updates?

[flooxo]

What would be the advantage of this?
The difference is that once PluginManager.UpdatePlugin and otherwise PluginManager.InstallPlugin is used. And update ensures that the old version is deleted first. So I would say pm update is fitting here

[jjw24]

@flooxo this is what you need:

Flow.Launcher/Flow.Launcher.Plugin/SharedCommands/FilesFolders.cs

Line 207 in 73f2c3b

public static bool IsLocationPathString(this string querySearchString)

Thanks! But this function does not check whether the location exists, which is crucial.

This method is best used to check if the query string is a location path, if not then proceed to download, if it is then you do a separate call to check if the file actually exists. This is so you don't end up checking file exists on disk per every query string.

So call that function on the passed in query string, if is location path then call this

Flow.Launcher/Flow.Launcher.Plugin/SharedCommands/FilesFolders.cs

Line 141 in 73f2c3b

public static bool FileExists(this string filePath)

[jjw24]

What would be the advantage of this? The difference is that once PluginManager.UpdatePlugin and otherwise PluginManager.InstallPlugin is used. And update ensures that the old version is deleted first. So I would say pm update is fitting here

Not sure if I am understanding correctly, but I would say the expected user experience would be to use pm install <file_path> to install and pm update <file_path> to update.

[jjw24]

Just a thought, whether pm update is a necessity here? If you need to constantly update your plugin from local file path, it would be when you are developing a plugin? Wouldn't be better to just dump/install the plugin into the plugins folder and open up the project from there anyway? Just a question more or less.

[flooxo]

Yes, sure. I've already thought about this point, but I think if you can install a plugin locally, then it should also be possible to update it for the sake of completeness. Of course, it would be easier to simply drag it into the folder.

[jjw24]

Hey @flooxo I would like to make a couple changes and refactor the code on this PR, do you like me to commit them here directly or show you via a new PR?

[flooxo]

Hey @flooxo I would like to make a couple changes and refactor the code on this PR, do you like me to commit them here directly or show you via a new PR?

Feel free to commit them directly here to keep things simple :)

[jjw24]

@flooxo hey I pushed my changes, they include:

• the zip file no longer gets deleted. Added an extra property to UserPlugin class to hold and determine a local install.
• moved the zip file read method into utilities class so no need to write the code in with the install/update methods
• created a new method to determine zip file path

Let me know if you see any issues with them.

[flooxo]

Nice, LGTM :)