Re: Packages

On Friday, March 4, 2016 at 11:37:08 AM UTC-6, Bram Moolenaar wrote:
> Ben Fritz wrote:
>
> > On Thursday, March 3, 2016 at 2:02:52 PM UTC-6, Bram Moolenaar wrote:
> > > Matthew Desjardins wrote:
> > >
> > > > On Friday, February 26, 2016 at 9:20:00 AM UTC-5, Matthew Desjardins wrote:
> > > > > There have been a couple of people posting about how the new package feature can, in its current state, replace Pathogen.
> > > > >
> > > > > https://groups.google.com/d/msg/vim_dev/BN5DuHpzzBc/OjoGDSqeEQAJ
> > > > > https://groups.google.com/d/msg/vim_use/QHqDKtdqUkk/PY7WydFdAQAJ
> > > > >
> > > > > Could someone explain how? It doesn't seem to work for plugins that
> > > > > don't have a "plugin" directory, and as far as I can tell from the
> > > > > source it's not supposed to, either.
> > > > >
> > > > > Why was this decision made to only support plugins with a "plugin"
> > > > > directory?
> > > >
> > > > If I'm understanding 7.4.1480 correctly, if something is just a syntax
> > > > file, for example, it has to go under "opts" and loaded manually with
> > > > ":packadd"?
> > >
> > > Either that or create an empty plugin file.
> > >
> > > I realize several people who have previously been using Pathogen are
> > > confused. Perhaps we can just put every directory under "pack/*/ever"
> > > in 'runtimepath'?
> >
> > If you're going to try removing the need for something like Pathogen,
> > then yes, you'll need to do something like that. Or just traverse
> > those directories as if they were on the runtimepath or something.
>
> There was no goal to replace Pathogen. The goal was to make it easier
> to drop a plugin, with all its related files, into a directory and have
> it work. And be able to do "git pull" (or the equivalent) to get the
> latest version. It did end up looking somewhat like Pathogen, but that
> is coincidental.
>
> When the first implementation for plugins was done it was a huge
> improvement over adding more lines to your .vimrc file. But now that
> plugins have grown to much larger sizes, with dependencies on different
> files that get scatterered in the runtime dirs, such as autload, we need
> something more.
>
> > The nice thing about Pathogen is that it makes installation of any
> > plugin dead simple: just unzip/clone that plugin into its own
> > directory under "bundle". That's it, there aren't any other required
> > setup steps and every plugin is treated the same.
>
> It also means that you can not have a group of plugins that depend on
> each other. The functionality is limited. E.g. if someone has three
> plugins that all use a common library (which would then also be called a
> plugin), you would get that common library three times. Or the docs
> would say "if you install this you also need to install that". Which
> defeats the idea of just dropping something in the right directory.
> And there is no mechanism to optionally load a plugin.
>
> > I think the current state of the Vim code not only offers nothing not
> > already available from Pathogen, it makes things much harder to use,
> > because you treat different types of plugin in different ways, and
> > SOMETIMES require a secondary installation step (but sometimes not).
>
> It does add the extra directory level, so that groups of plugins can be
> installed together. Some installed always, some optionally (or when
> needed or when specific features are present, e.g. Python).
>
> This does make it a bit more complicated, but the docs have the one
> extra command to do it:
> % mkdir -p ~/.vim/pack/my/ever/always
> % cd ~/.vim/pack/my/ever/always
> % unzip /tmp/myplugin.zip
>
> > MAYBE plugin managers will start using these features, but since
> > they've already found ways to work using the current "runtimepath"
> > setting, which will also work in older Vims, I don't know why they'd
> > bother.
> >
> > If the goal was not to replace Pathogen, and it was not to make it
> > easier to install plugins, but rather to control the explosion of
> > runtimepath from existing plugin manager solutions, then it looks like
> > the new code fails at that as well.
>
> I tried to avoid the explosion of 'runtimepath', but it appears so many
> users and plugins already rely on it (see the response in this thread)
> that I had to give up on it. Also, it seems nobody is complaining about
> the long path.
>
> So I added 'packpath' as the short alternative.
>
> > Maybe it's time to step back and document the goals of this new
> > interface and design a coherent system to address each goal before
> > throwing code at it. The current state seems rather ad-hoc and I'm not
> > sure what problem it's solving. I think most people assumed the
> > original try with pack/*/ever would work just like Pathogen and not
> > only on plugin/* files.
> >
> > I haven't read the help files on the topic yet (if there are any) so
> > perhaps those make things clearer.
>
> :he packages
> :he 'packpath'
> :he loadplugin
>
> Please read docs before making comments....
>
>

Fair enough. I just read the version that came with 7.4.1467 and I'm quite confused.

For Pathogen, you install by unzipping all files for a plugin, into a directory under "bundle":

~/.vim/bundle/someplugin/plugin/foo.vim
~/.vim/bundle/someplugin/autoload/bar.vim
~/.vim/bundle/someplugin/syntax/beez.vim

With packages, the default 'packpath' is the same as runtimepath. The example code creates a ~/.vim/pack/my/always directory. Is "always" synonymous with "someplugin" above? I.e. is "always" what you'd get from cloning an existing plugin not designed specifically for a packages setup?

What's "my" for? Is that the way to package multiple plugins together? Is it necessary or can "someplugin" go directly under "pack"? The help just mentions looking for an "ever" directory, it doesn't talk about any intervening directories.

You talked about dependencies...with this method, won't you potentially have multiple copies of every dependency, if every plugin that has a dependency defines a package instead to bundle the plugin with all its dependencies?

From the help for 'packpath' I expected every directory under ~/.vim and ~/.vim/after to be searched recursively for an "ever" directory. I don't see anything special about the "pack" directory in the help, but just putting a new "ever" directory under my existing "bundles" and moving anything inside doesn't seem to do anything. Is it because I need a "my" directory of some kind? Or is "pack" actually special? How does 'packpath' relate to this?

--
--
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.