This seems like a good idea. I'd like to know a little more though:

• How does the synopsis section of the POD look?
• Is it compatible with non-Exporter.pm exporters?
• Do you trace only subroutines?
• How is the actual tracing done?

A synopsis and a brief summary of the implementation would really help.

lodin

Here's the synopsis:

    SYNOPSIS

    # Wrap all subs in default code to warn on entry/exit, displaying 
+args and return values...
    use Devel::WrapExports;

    # The same thing, but ignore the specified packages and subs...
    use Devel::WrapExports
        exempt_pkgs => [ qw( Devel Carp CGI ) ],
        exempt_subs => [ qw( Nevermind::me ) ];

    # Use my own subs for tracing instead of the defaults...
    use Devel::WrapExports
        pre   => q{ sub { "custom pre-wrapper..."  } },
        post  => q{ sub { "custom post-wrapper..." } };

    # Run as script to list fully-qualified names of each symbol (sub 
+or otherwise) in the top-level scope...
    $ perl /path/to/Devel/WrapExports.pm <perl-source-file>
[download]

Some more background:

Initially, I only wanted to know where to go to find the source of hundreds of imported subs in code that I was looking at. Then, I realized that if I could automatically wrap all imported subs with warnings on entry/exit, I could get a nice trace in Apache error logs.

Currently, the technique is to look at all packages that are explicitly 'use'd or 'require'd by the caller (these are found by examining the caller's source code), then find all symbols that each of those packages export (this is done by looking at the contents of @EXPORT and @EXPORT_OK in each of these packages' symbol tables, so it's not compatible with non-Exporter.pm exporters). For each such symbol that is a sub, exploit Hook::LexWrap to wrap the sub (the one already imported into the caller's package) with "tracing code" as implied in the SYNOPSIS above (e.g. default or custom tracing subs).

Your question about handling non-Exporter.pm exporters is a good one. I hadn't considered that in my focused mindset. I plan on adding that support. It will be a matter of looking at the caller's symbol table instead of the caller's source (which is almost certainly a better approach anyhow).

So, in summary:
• I'm planning on supporting non-Exporter.pm exporters.
• Only subs are traced (by design), using Hook::LexWrap (but calling the module as a program shows all types of symbols in the package of the argument).

The name
If you plan to support only subroutines I don't think it should be called Devel::WrapExports. That name sound more generic and the way I interpret it is that the exporter mechanism will be wrapped to allow me to inspect everything that was exported. I don't know what a better name would be, but the uncommonly long Devel::WrapImportedSubs doesn't seem to bad after all. Imperfect as it may be the concept is clearly communicated. "Devel" - it's to help development; "wrap" - you do something upon each call; "imported" - only imported subroutines are of interest; "subs" - only subroutines are of interest. Note that I suggest "imported" over "exported" because you do it from a caller perspective. The package doing "use Devel::...;</c> later imports from the modules it uses. "Export" makes sense from the module author's perspective (like used as Exporter.pm), e.g. if a module Foo wanted to register every case of use Foo;.

The interface
I think that you have a good interface. However, I think you should open up to other ways of wrapping. Hook::LexWrap is convenient, but it can also break code that relies on caller(). It's possible (and simple) to do a completely transparent pre-hook, so another way to install the hook is quite important.

The implementation
Good luck. I think you'll need it. :-) It's quite a complicated task; there are several tricky cases. I'm looking forward to seeing how you solved it.

lodin