in reply to Re: [RFC: Module proposal] Tracing sneaky EXPORTs using wrappers
in thread [RFC: Module proposal] Tracing sneaky EXPORTs using wrappers

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:
  • Comment on Re^2: [RFC: Module proposal] Tracing sneaky EXPORTs using wrappers
  • Download Code

Replies are listed 'Best First'.
Re^3: [RFC: Module proposal] Tracing sneaky EXPORTs using wrappers
by lodin (Hermit) on Apr 12, 2008 at 01:09 UTC

    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

[reply]
[d/l]
[select]
      Your naming advice makes perfect sense to me. However, after more consideration of the implementation goals I had proposed, I'm now wondering if I should be a bit less ambitious and settle for something that will probably be just as useful anyway. I believe my original plan to deterministically identify the origin package for imported symbols would be more realistic if I drop the goal of supporting non-Exporter.pm exporters.

      You're right about the edge cases -- there are some tough ones. I believe that most of the ones I've thought of are within reach. For instance, one interesting problem is identifying which of all the use()d modules contributes symbol S to package P (or if S just came from P itself). I believe I could create a private, empty package in which a candidate module could be use()d, then check the resulting symbol table of the dummy package for symbols. The resulting set of symbols would represent those exported by the module's import().

      However, symbols not found this way might still have come from those modules (e.g. the package in question could require() a module M, then call M::import_deceptively(), which may do what import() conventionally does)! The probability of false negatives would be very low, but I can't think of a general way to positively conclude that a symbol has not been imported.

      I have a new appreciation for Exporter.pm, much maligned as it has been at times. As it is standard for Perl, placing dependence on it as a precondition for my module's efficacy seems reasonable.

      Here are the updated goals for Devel::WrapImportedSubs:
      • Wrap subs that use()d modules have exported via Exporter.pm (by looking for @EXPORT and @EXPORT_OK in their symbol tables)
      • Optionally wrap subs defined by the caller and fully-qualified subs called from other namespaces (since it would seem that users (like me) who need to do tracing would expect and need this easy-to-add feature)
      I'll think about alternatives to Hook::LexWrap.

      Thanks for help with advice on the design!
[reply]

In Section Meditations