On Mar 24, 2014 11:08 AM, "LCD 47" <lcd047@gmail.com> wrote:
>
> On 23 March 2014, ZyX <zyx.vim@gmail.com> 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 vim_use+unsubscribe@googlegroups.com.
> 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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment