On Fri, Oct 9, 2009 at 3:31 PM, Ricardo Signes <perl.cpanw...@rjbs.manxome.org> wrote: > * Ruslan Zakirov <ruslan.zaki...@gmail.com> [2009-10-09T15:28:29] >> On Fri, Oct 9, 2009 at 3:47 PM, David Golden <xda...@gmail.com> wrote: >> > 12. Allow Sequences (Arrays) for Prereqs >> > >> [snip] >> > order by using a sequence of pairs, Bundle's magic could probably be >> > made obsolete, simplifying the toolchain overall (over a long deprecation >> > period). >> [snip] >> >> Always, thought that Bundles are about optional deps. Like "hey, here >> is Bundle for this module that installs all cool features you don't >> get by default becuase of optional dependencies". > > When I have said, in the past, "I wish Bundles were replaced entirely by > Tasks," the response I got a number of times was, "but Bundles let you fix the > install order."
They do, and occasionally it has been useful. The other major feature of Bundles it that you can specify *distributions* not just *modules*. I.e. RJBS/Foo-Bar-1.23.tar.gz -- allowing older or even development versions. > It this is not an issue, and we would rather always allow the installing > client > to determine order, I am less interested in this. I'm leaning towards using an array and having the client attempt an order-preserving dependency resolution (*should* preserve). So for [A, B, C], A's deps are resolved then A is installed, then B's deps are installed then B is, then C's deps and C. If B depends on A and C depends on A and B, then it's just A => B => C. If a naive META generator just alpha sorts or uses whatever order results from "each %prereq", the client will still install them correctly, but a smart/custom META could pre-resolve the dependency order if needed. -- David
