People wanting to re-export your module should also be using Import::Into. Any exporter or pragma will work seamlessly.

Note: You do not need to make any changes to Thing1 to be able to call import::into on it. This is a global method, and is callable on any package (and in fact on any object as well, although it's rarer that you'd want to do that).

Exporting on someone else's behalf is harder. The exporters don't provide a consistent API for this, and pragmas need to have their import method called directly, since they effect the current unit of compilation.

The APIs for exporting modules aren't consistent. Exporter subclasses provide export_to_level, but if they overrode their import method all bets are off. Sub::Exporter provides an into parameter but figuring out something used it isn't trivial. Pragmas need to have their import method called directly since they affect the current unit of compilation.

It's ... annoying.

However, there is an approach that actually works for all of these types.

eval "package $target; use $thing;"

will work for anything checking caller, which is everything except pragmas. But it doesn't work for pragmas - pragmas need:

$thing->import;

because they're designed to affect the code currently being compiled - so within an eval, that's the scope of the eval itself, not the module that just used you - so

Of course, now you have two new problems - first, that you still need to know if something's a pragma, and second that you can't use either of these approaches alone on something like Moose or Moo that's both an exporter and a pragma.

which means that import is called from the right place for pragmas to take effect, and from the right package for caller checking to work - and so behaves correctly for all types of exporter, for pragmas, and for hybrids.

Additionally, some import routines check the filename they are being imported to. This can be dealt with by generating a #line directive in the eval, which will change what caller reports for the filename when called in the importer. The filename and line number to use in the directive then need to be fetched using caller:

And you need to switch between these implementations depending on if you are targeting a specific package, or something in your call stack.

Remembering all this, however, is excessively irritating. So I wrote a module so I didn't have to anymore. Loading Import::Into creates a global method import::into which you can call on any package to import it into another package. So now you can simply write:

use Import::Into;
$thing->import::into($target, @import_args);

This works because of how perl resolves method calls - a call to a simple method name is resolved against the package of the class or object, so