Hi, On Tue, 03 May 2022 17:06:20 +0200 meik michalke <meik.micha...@uni-duesseldorf.de> wrote: > i think we should also address the plugin management section. mine is > pretty crowded because i have several versions of some plugins (or > multiple copies of the same version in various places, like installed > with older R versions).
true, it's a bit of a mess... > RKWard currently keeps the currently active > version and warns you, allthough you probably would like to also > update the active plugin when the package is being updated, right? > > it would be helpful if plugins were sorted by ID with one nested > entry for each ID and a radio button to select the relevant one that > is used of the plugin is active, e.g. > > [x] my plugin > (o) version 0.1-2, /path/to/plugin/R4.2 > ( ) version 0.1-2, /path/to/plugin/R4.1 > ( ) version 0.1-1, /path/to/plugin/R3.6 > [ ] another plugin > ( ) version 0.1-2, /path/to/plugin/R4.2 > (o) version 0.1-2, /system/path/to/plugin/R4.2 +1 for the grouping by ID, but I wonder whether the additional selection is really needed, and beneficial. I forsee a situation where users will never see an update, because at some point they selected the version in some outdated R library location that they are not even aware of. Arguably, of course, that is the situation we're already in. Anyway, would it make more sense to come up with smarter auto-selection? Obvious sorting criteria would be timestamp, and version number (where a reasonable assumption might be that pluginmaps with the same version number are identical). In theory, it _might_ also be possible to priority pluginmaps that are installed inside the current .libPaths(). (I'm not sure about the implications of the latter). Regards Thomas
pgpkH_CnfwZ44.pgp
Description: OpenPGP digital signature
