Bug#827627: Please support packaging vim addons as vim "packages"

[Josh Triplett]

On Sat, Jun 18, 2016 at 11:55:17PM -0400, James McCoy wrote:
> On Jun 18, 2016 6:03 PM, "Josh Triplett" <josh at joshtriplett.org> wrote:
> > [Note: in addition to changing vim-addon-manager, this would ideally go
> > along with some minor updates to the vim packaging policy in the vim
> > package; I'd be happy to supply a patch for that.]
> 
> N.B., vam already has some support for using a directory to contain a
> plugin, like pathogen does. This wasn't officially announced because of a
> bootstrapping issue which is now solved with Vim's packages.
> 
> I'm currently working on getting that merged in NeoVim so we can have
> consistent handling.
> 
> > This format has the advantage that the user can add a single directory
> > (or symlink) for a package, keeping all that package's files together.
> 
> Agreed. It solves a number of issues which have been the main things
> holding me back from updating the vim-scripts package.

Awesome.

> > I would suggest installing packages under /usr/share/vim/packages, and
> > replacing the "files" key in the registry yaml files with "package:
> > pkgname", where pkgname matches the top-level directory in
> > /usr/share/vim/packages.  When installing a package, vim-addon-manager
> > should just make a single symlink from ~/.vim/pack/$pkgname to
> > /usr/share/vim/packages/$pkgname.
> 
> Good suggestions.  We currently use ~/.vim/bundle iirc, but since I don't
> think it's really used anywhere, I'd be fine changing it.

Some of the "automatically download and run code from github" plugin
systems use "bundle".  vim's built-in package handling uses "pack".

> My remaining quandary is how to properly handle disabling a systemwide
> plugin while not interfering with a user's plugin of the same name (e.g.,
> installing a newer version locally when the sysadmin also has it enabled).

I don't think that issue works any better with the current
non-package-based approach, and I don't think this change has to solve
all problems.  The "disable" mechanism already exists to handle
disabling a system-wide enabled package.  If a user wants to override a
system-wide enabled package, they could potentially override runtimepath
or packpath to leave out the system directories.  (Or complain at the
sysadmin for enabling a vim package system-wide on a multi-user system.)

- Josh Triplett