downloading a package and then removing things sounds wrong.
i expect to either be able to download a package and install additional plugins as needed or to have multiple downloads to pick the best match and then still install additional plugins on top if needed.
i’m kinda wondering if we couldn’t improve the plugin installation process a bit: already now we’re using
elasticsearch-plugin install with a
file:/// path (fun-fact: i had an RTFM moment when i failed to notice that i need to use
file:/// for it to work and use absolute paths when i ran it with
./someplugin.zip ), maybe it would be possible to use a central plugin repository (i wouldn’t invent something new here, probably using github packages, maven central or similar would work) and then just be able to write
opensearch-plugin install someplugin:1.2.3 and it’ll try to fetch it from that default location.
add the options to install multiple plugins at once (à la
opensearch-plugin install someplugin:1.2.3 otherplugin:3.2.1), install “latest compatible version” (i.e. just don’t specify a version number:
opensearch-plugin install someplugin) and things should be very easy to use.
then the download package could even contain all default opensearch plugins - but not installed but instead just as pre-delivered versions for those which need to install in places w/o internet access (though you could also say that this is a corner-case and they can just download the plugins as normal).
but i’d definitely not see these as mandatory features for a 1.0.0 release but instead would just see them as nice-to-have (but obviously the vision would have an impact on packaging considerations already now).