Dist::Zilla::Plugin::Beam::Connector

This module aims to allow "Dist::Zilla" to use plugins using
"Beam::Event" and "Beam::Emitter", and perhaps reduce the need for
massive amounts of composition and role application proliferating
"CPAN".

This is in lieu of a decent dependency injection system, and is
presently relying on "Dist::Zilla" to load and construct the plugins
itself, and then you just connect the plugins together informally,
without necessitating each plugin be specifically tailored to the
recipient.

Hopefully, this may also give scope for non-"dzil" plugins being
loadable into memory some day, and allowing message passing of events to
those plugins. ( Hence, the "plugin:" prefix )

A Real World Example of what a future could look like?

  [GatherDir]

  [Test::Compile]

  [Beam::Connector]
  on = plugin:GatherDir#collect => plugin:Test::Compile#generate_test

"GatherDir" in this example would build a mutable tree of files, attach
them to an event "::GatherDir::Tree", and pass that event to
"Test::Compile#generate_test", which would then add ( or remove, or
mutate ) any files in that tree.

Tree state mutation then happens in order of prescription, in the order
given by the various "on" declarations.

Thus, a single plugin can be in 2 places in the same logical stage.

  [Beam::Connector]
  on = plugin:GatherDir#collect => plugin:Test::Compile#generate_test
  ; lots more collectors here
  on = plugin:GatherDir#collect => plugin:Test::Compile#finalize_test

Whereas presently, order of affect is either governed by:

*   phase - where you can add but not remove or mutate, mutate but not
    add or remove, remove, but not add or mutate

*   plugin order - where a single plugin cant be both early in a single
    phase and late

If that example is not convincing enough for you, consider all the
different ways there are presently for implementing "[MakeMaker]". If
you're following the standard logic its fine, but as soon as you set out
of the box, you have a few things you're going to have to do instead:

*   Subclass "MakeMaker" in some way

*   Re-implement "MakeMaker" in some way

*   Fuss a lot with phase ordering and then inject code in the "File"
    that "MakeMaker" generates.

These approaches all work, but they're an open door to everyone
re-implementing the same thing thousands of times over.

  [MakeMaker]

  [DynamicPrereqs]
  -phases = none

  [Beam::Connector]
  on = plugin:MakeMaker#collect_augments => plugin:DynamicPrereqs#inject_augments

"MakeMaker" here can just create an "event", pass it to
"DynamicPrereqs", "DynamicPrereqs" can inject its desired content into
the "event", and then "MakeMaker" can integrate the injected events at
"wherever" the right place for them is.

This is much superior to scraping the generated text file and injecting
events at a given place based on a "RegEx" match.

INSTALLATION

This is a Perl module distribution. It should be installed with whichever
tool you use to manage your installation of Perl, e.g. any of

  cpanm .
  cpan  .
  cpanp -i .

Consult http://www.cpan.org/modules/INSTALL.html for further instruction.
Should you wish to install this module manually, the procedure is

  perl Makefile.PL
  make
  make test
  make install

COPYRIGHT AND LICENSE

This software is copyright (c) 2016 by Kent Fredric
<kentfredric@gmail.com>.

This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.