[wp-trac] [WordPress Trac] #22316: Plugin Dependencies (Yet Another Plugin Dependencies Ticket)

[WordPress Trac]

#22316: Plugin Dependencies (Yet Another Plugin Dependencies Ticket)
--------------------------+------------------------------
 Reporter:  Viper007Bond  |       Owner:
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Plugins       |     Version:  3.4.2
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |     Focuses:
--------------------------+------------------------------

Comment (by MikeSchinkel):

 Replying to [comment:76 ideag]:
 > I had a free weekend some time ago, so I built a proof-of-concept plugin
 that illustrates a simple way, how plugins could declare some dependencies
 via plugin headers: https://github.com/ideag/tinylibraries

 Replying to [comment:77 tazotodua]:
 > With my opinion, plugin dependency in "plugin header" is the most
 undesired way.
 > I think "dependencies" list should be dynamic (dynamic function is much
 flexible), within plugins own variable, like:

 My two cents:  Plugin Header is the way to go and then WordPress core
 should just ''"handle it."''

 @ideag: That said, how does TinyLibraries handle incompatible versions?
 Let's say I have Foo plugin and Bar plugin and they both use Baz library,
 but Foo uses 1.3 and Bar uses 2.5.   Assuming [http://semver.org/ SemVer]
 then you'd have a situation where either Foo or Bar would be run on the
 site but not Foo and Bar at the same time because their different versions
 of Baz would conflict.

 I wrote a library 5 years ago(!) called
 [https://github.com/newclarity/imperative Imperative] whose goal was to
 allow inclusion of a library that would ''(theoretically)'' never change
 and thus any plugin could load it and be confident they had the right
 version.  In it is a `register_library()`method that allows a plugin to
 register the libraries it needs.

 Imperative uses the rules of SemVer which means that if Foo plugin uses
 Baz library `1.3` and and Bar plugin uses Baz library `1.7` then
 Imperative would load only `1.7` which should theoretically satisfy both
 Foo and Bar.  But if a new version of Bar came alone with Baz library
 `2.0` then Imperative would tell the user they could not activate Baz
 unless they disable Foo. It also suggests to contact the developer of Foo
 to get them to upgrade to Baz 2.0.

 But what I found out was that Imperative was rather fragile because
 WordPress did not have enough hooks and was very inconsistent in how core
 works with plugins in the areas that Imperative needed to deal with and
 that the core team was not interested in addressing any of the issues so I
 gave up on developing plugins ''(and focused on the individually more
 profitable approach of developing complex websites for clients.)''

 Even so I would still love to see dependencies addressed in core.  But to
 do so would require dealing with incompatible library versions if they are
 to be shared among plugins and themes.  Although I fear it will never
 happen.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/22316#comment:80>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform