mstpan 14 - Exporting
Namespace all the things!
Exporter
Exporter itself is the original, classic, in-core means of getting utility subroutines into other people's namespaces.
It offers a default list (which should be used sparingly unless your module will only ever export one or two functions), a list of optional exports, and groups thereof.
If this is sufficient for your use case, I see no reason not to use it.
Sub::Exporter
The first significantly popular rich exporter, Sub::Exporter provides two important things - generated exports and export renaming. The API is based around basically passing it a giant configuration hashref, which I get really annoyed by but most people seem to find perfectly reasonable.
This is well worth a look, especially if you hate the Exporter API.
Sub::Exporter::Progressive
This module avoids much of the dependency tree of Sub::Exporter by providing only the most common usages of it and attempting to load Sub::Exporter itself when its capabilities are exceeded.
This is lovely for making Sub::Exporter code lighter weight for e.g. fatpacking, at the cost of requiring downstream users that need the full feature set to specify Sub::Exporter as a dependency themselves.
Moose::Exporter
A system for building exporters that setup Moose classes/roles, based upon Sub::Exporter. If you're attempting to build a Moose extension of some sort (rather than simply a thing that uses Moose) then this is almost certainly what you wanted to be using.
Exporter::Tiny
Written to provide a similar feature set to Sub::Exporter but with minimal dependencies even when using the full capabilities.
The author also chose to go back to a much more Exporter-like interface, for which I could hug him but presumably fans of the Sub::Exporter interface disagree on.
If you're exceeding the capabilities of Exporter but comfortable with it, or if you need export renaming or generated exports with minimal dependencies, this is the recommended option.
Exporter::Declare
Maximum overkill, up to and including offering optional Devel::Declare based keyword sugar and an extensible meta-export-model. If everything else seems anaemic, look here before rolling your own.
namespace::(auto)clean
namespace::clean will remove any/all subroutines present in your namespace when it's invoked at the end of compile time. This means that they don't end up lying around to accidentally get called as/clash with methods - which for things like DBIx::Class::Candy is essential, but generally useful for all OO code.
namespace::autoclean removes everything that "looks like" an import, i.e. came from a different package. If you're already not fatpackable, it's almost certainly a better answer than namespace::clean - but bear in mind that while it always works with Moose, you need Sub::Name installed for it to work with Moo.
Either option is almost always strictly better than 'no Moose;' and similar unimport invocations.
Import::Into
Written to make it possible to build a mixed bundle of pragmas and exports without losing SAN points. If you're finding your code clogged up by boilerplate use-ing the same set of things in lots of packages, this is how to build a bundled version that exports all of them correctly.
You may also like Import::Base, which provides a more delcarative API for deciding what to apply Import::Into to.
It's entirely possible this should've been called Export::Into instead, and highly probable the author is bad at deciding what to cache to boot.
-- mst, out.