On Monday, March 7, 2016 at 3:24:07 AM UTC-6, ZyX wrote: > 2016-03-07 8:24 GMT+03:00 Benjamin Fritz <[email protected]>: > > > > > > On Sat, Mar 5, 2016 at 7:27 AM, Bram Moolenaar <[email protected]> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
