Re: Packages

On Monday, March 7, 2016 at 3:24:07 AM UTC-6, ZyX wrote:
> 2016-03-07 8:24 GMT+03:00 Benjamin Fritz <fritzophrenic@gmail.com>:
> >
> >
> > On Sat, Mar 5, 2016 at 7:27 AM, Bram Moolenaar <Bram@moolenaar.net> wrote:
> >>
> >>
> >> Ben Fritz wrote:
> >> > 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.
> >>
> >
> > Ah, so this would be where true plugin managers come in. A plugin manager
> > could be expected to track the dependencies between multiple plugins and
> > create a package for all related plugins in a group.
>
> Without isolated namespaces this is absolutely useless behaviour. If A
> depends on B, C depends on B and D does not depend on anything and
> plugin manager created packages (A,B1), (C,B2) and (D) then out of B1
> and B2 there will be only one used, whatever was found first (or last
> or first with errors from last, depending on how plugins and plugin
> manager are written). On the other hand creating package (A,B,C) and
> (D) if B is a library, A and D are filetype plugins and C is a
> universal linter would be rather strange choice, also where plugin
> manager is going to pull a package name from? Not to mention what is
> needed to be done if a plugin E is added that depends on D and B?
> Moving plugins around without an explicit reason is not fine.
>
> So if plugin manager is using packages it will create one package
> containing all plugins. Maybe additionally a user-defined packages
> that are needed to group plugins loaded at request by user when it is
> needed to load at one request more then one plugin, without "grouping
> by dependencies" nonsense.
>

Sorry, my meaning was more that "plugin managers will solve the problem of not grabbing multiple copies of each plugin". I did not necessarily mean "plugin managers will be able to manage different version of the same dependency". Sorry that I was not more clear.

I was envisioning distributions of 2 different plugins, each depending on a third plugin C.

If A and B both distribute as a *package* also containing C then a naive installation by the user with two separate packages would cause problems.

My point was that a plugin manager could be smarter and only grab one copy of C, placing A, B, and C in a package together. That's all I meant by "create a package for all related plugins".

Is that more correct?

Regardless, talking about the finer points of package management via a plugin is probably not needed in the help.

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