Re: Packages

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


--
I have read and understood the above. X________________

/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

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