Test::Stream will still have a no non-core dep policy, so depending on both Test-Stream and Test-Builder effectively adds 1 dep, that is not burdensome.
On Sat, May 2, 2015 at 3:34 PM, Aristotle Pagaltzis <pagalt...@gmx.de> wrote: > * Sawyer X <xsawy...@gmail.com> [2015-05-02 23:05]: > > Effectively what happened/happens is that, while plugins are now able > > to provide two different implementations without worrying about > > backwards compatibility (we originally wanted it to be seamless but > > turned out to be very hard), most plugins had a shared core. This was > > odd to maintain. You either fork it or you put it in a common "::Core" > > module, or you ship both in the same distribution. > > I was going to suggest shipping both in the same distribution – in fact > if the code is completely identical you could put them in one file and > basically just alias one namespace to the other, which seems desirable > as it reduces the maintenance burden to “essentially free” – but there > is a problem with that: dependencies and testing. > > Essentially the only sane thing is to declare dependencies on both of > the ecosystems. Then you can also run your tests against each of them. > > But this obviously sucks for users. > > Yet the alternatives are worse. One of them is you pick one ecosystem as > the preferred one. That sucks for users on the other side. Or you do not > declare dependencies on *either* of them – which sucks for everyone. > > Also, the tests for any ecosystem that is not declared as a dependency > will have to skip. But the user might then install that ecosystem’s core > later, and then your plugin magically is already installed in spite of > its tests against that ecosystem never having run. > > (Conversely if the user has both ecosystems installed and the tests for > one of them fail but the tests for the other do not, there is no way to > install the plugin for just one ecosystem but not the other.) > > All of this insanity is avoided if there is one plugin for one ecosystem > and another for the other. Then they can each declare their dependency > on the right one, and their tests for it can be run unconditionally, and > if they fail, the other ecosystem’s version of the plugin is unaffected. > > But shipping a ::Core plus a wrapper for each ecosystem means you have > to ship (at least) 3 distributions, and every plugin comes in 2 parts. > That’s pretty annoying. > > I think the right answer here is “Dist::Zilla plugin”: i.e. you maintain > a single codebase, in a single repo – but at release time, the authoring > tool of your choice bakes you two distinct distributions to upload. The > code in the repo can then be two-faced, and `prove` ought to run both > sets of tests. This makes it natural from the maintainer’s perspective. > And if the versions of the plugin need to diverge, from the perspective > of the CPAN index, that transition to separate codebases is invisible. > > Regards, > -- > Aristotle Pagaltzis // <http://plasmasturm.org/> >
