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

"always" is just a name. You got the directory name wrong. I renamed
to avoid confusion. So now for one plugin:

If you don't have a package but a single plugin, you need to create the extra
directory level:
% mkdir -p ~/.vim/pack/my/ever/something
% cd ~/.vim/pack/my/ever/something
% unzip /tmp/myplugin.zip

You would now have these files:
pack/my/ever/something/plugin/foo.vim
pack/my/ever/something/syntax/some.vim

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

"my" is the name of the package that you choose. As the help says:

The directory name "my" is arbitrary, you can pick anything you like.

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

I would expect people who create several plugins that depend on a common
library to have one package with all these plugins.

If a plugin depends on something made by another, you can clone that and
add it to your package. The advantage is that you can test that
specific version. Might have a name conflict if the user downloads it
separately, thus you may want to rename it. And of course keep it
updated.

Otherwise you can always depend on something that's downloaded
separately.

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

All packages go under "pack".

--
I once paid $12 to peer at the box that held King Tutankhamen's little
bandage-covered midget corpse at the De Young Museum in San Francisco. I
remember thinking how pleased he'd be about the way things turned out in his
afterlife.
(Scott Adams - The Dilbert principle)

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