Create plugin add to place plugin in proper directory
Currently notation plugin only officially supports the list command. It is confusing, error prone, and time consuming for users to have to go lookup what the proper directory is for plugins. Suggestion is to add support for notation plugin add <name> <path-to-local-plugin-file> which automatically creates the proper directory and adds the plugin file there.
This might be more challenging for a multi-file plug-in that might be written in Java or .net if the expectation is to copy the plug-in over.
Expectation would be to copy the file over. It was my understanding that a plugin must be a single executable file - at least that's what I was reading in the code.
@gokarnm any inputs on this?
I agree that expecting users to copy over files to appropriate plugin location is error prone and bad CX. This is not prioritized for RC1 by should be by GA release.
The plugin itself can be a set of files, containing the executable and any dependencies, and is expected to be placed in a sub directory with matching name e.g ~/notation/plugins/com.example.nv2plugin/notation-com.example.nv2plugin.
Something like notation plugin add <name> <path-to-local-plugin-directory> would work better, and does the following
- Validate that plugin executable exists as per plugin executable naming convention, and has correct permissions
- Create directory
namein plugin base directory - Copy all the file in
path-to-local-plugin-directoryto the plugin sub directory.
We also have a notion of system and user level paths for plugin base dir, so probably will need a switch for it and a default value.
The multi-file thing is a good issue. Perhaps we can pass in a file, or a directory. This behavior did previously exist, but it was single-file based. It's another good first issue for someone to pickup
We should also consider an approach similar to Docker plugin.
i.e. notation plugin install <name>
Can I work on this?
@dtzar Could you confirm it is duplicate of https://github.com/notaryproject/notation/issues/549, which provides more details and context. Maybe we could close this one and track #549
Agree 549 is duplicate, solves the problem, and has more detail on a design for implementation than this issue