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.
> 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).
> 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.
> ---
>
> 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.
No comments:
Post a Comment