On Mar 24, 2014 11:08 AM, "LCD 47" <[email protected]> wrote: > > On 23 March 2014, ZyX <[email protected]> wrote: > [...] > > A list of things I would expect from a plugin manager: > > > > 1. Installing plugins in a FHS-compatible fashion (i.e. in > > /usr/share/vimfiles/...). Target directory must be configurable. Reason: to > > respect package maintainers from various distributions and do not make them > > duplicate installing functionality on their end. > > 2. Outputting dependency list in a standard way. Reason: to make tools like > > `g-cpan` (automatically generates Gentoo ebuilds for perl packages) able to > > exist. It again prevents duplicating work on a distribution maintainers side. > > 3. Exact versions installation and dependencies with versions. Reason: new > > versions of plugins may be incompatible with dependent plugins, or may have > > some functionality removed. > > Three other related features might come in handy here: > > - a list of conflicting plugins, with versions > - a list of conflicting settings in other plugins > - a list of required Vim features and / or version restrictions. > > > Low priority, because usually there are no compatibility problems > > if you just use latest versions of all plugins. > > Sadly, this point goes down the drain as soon as the user locks > a plugin to a certain version (presumably because newer ones break > something). No, this is likely to turn out to be a crucial feature > (and probably also impossible to get right). > > > 4. Ability to recognize presence of plugins that were not installed by itself or > > some index of installed packages with an official API functions to manipulate > > it. Reason: make it able to mix system-wide installed plugins and user-local > > installations, assuming system-wide will be installed by system plugin > > manager; it also enables distribution maintainers to just rely on plugin > > manager to install required plugin. > > 5. Ability to ignore package dependencies. Reason: overlaps with 4: enable > > distribution maintainer to just rely on plugin manager and on the fact that > > it under no circumstances will fetch unwanted dependency so it won't leak in > > the binary package. > > > > --- > > > > 6. Ability to install plugins to a separate directory. Reason: for user it is > > easy to find which files relate to which plugin. > > 7. Ability to update plugins without changing installation directory, ignoring > > system-wide (if invoked from regular user) or user-local (if invoked from > > root) installation updates. Reason: centralized updates are convenient. > > 8. Ability to track and preserve user changes to installed plugins or ability to > > halt updating process if files were modified. Reason: some plugins expect > > users to configure them in the same directory they are located in (example: > > snipmate) or are simply not configurable. > > Not really feasible if the source of the plugin is not in a VCS of > some sort.
VAM has working implementation. It is required to hold original archive though. VAM relies on VCS if plugin uses VCS though. > > > 9. Ability to run certain code on plugin installation and update. Possibly also > > during uninstallation. Reason: some plugins require building of their C code, > > some simply have incorrect directory structure so that it is needed to copy > > files. > > 10. Ability to work with all kinds of sources present on www.vim.org. Reason: > > you cannot really expect plugin authors to massively change archive types. > > Well, if you want to get rid of the existing mess of formats, now > would be the right time (and probably an opportunity we might never come > to again in the foreseeable future). What for? Archive formats support is not much of a burden. > > > 11. Ability to work with VCS sources. Reason: some plugins are available only > > from github, some have useful features that were not released yet. > > 12. Ability to remove plugins. Reason: centralized removal is convenient as > > well. Low priority. > > 13. Ability to list and remove unused plugins. Reason: it is just convenient. > > Low priority. > > That would imply keeping stats about when each plugin is actually > used. A complicated, expensive, and tricky task, for very little gain. Simplest implementation is just taking a list of currently active plugins and remove everything but them. VAM/Vundle/NeoBundle have everything what is necessary to perform such a task. It is not so easy for FHS-based installations, but it is easy to implement if you just do not provide this functionality for this task. And check out :scriptnames. Recording its output at VimLeave makes such functionality rather easy. > > > --- > > > > 14. Ability to specify location where to download sources and where to take > > downloaded sources from. Reason: if user has spoiled installation make it > > easy and fast to reinstall, if user has no Internet connection make it > > possible to install. Low priority. > > 15. Ability to list URLs to download (possibly in a shell script). Reason: if > > user has no Internet connection make it still some sort of usable. Low > > priority. > > A very well thought-out list. > > /lcd > > -- > -- > You received this message from the "vim_use" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups "vim_use" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
