What is this module using?

Discussion in 'Perl Misc' started by Tim McDaniel, Apr 18, 2012.

  1. Tim McDaniel

    Tim McDaniel Guest

    Looking at the docs, it appears that Devel::Modlist reports on *all*
    the modules used in an entire script. Is there some way I can
    determine the modules used, directly or transitively, merely by the
    current module?
     
    Tim McDaniel, Apr 18, 2012
    #1
    1. Advertisements

  2. Tim McDaniel

    Reini Urban Guest

    For an easier way, I'd rather print the %INC keys in an END block, as
    require stores the loaded module names there.

    perl -mCPAN -e'END{print(join qq(\n),keys %INC)}'

    This does not print the package names per se, but the relative paths of
    all loaded modules.
    s{/}{::}g; s{\.p[lm]$}{}; will do pretty printing of the names.
     
    Reini Urban, Apr 30, 2012
    #2
    1. Advertisements

  3. Tim McDaniel

    Reini Urban Guest

    Oops, you are right, yes.
     
    Reini Urban, May 1, 2012
    #3
  4. Tim McDaniel

    Tim McDaniel Guest

    Back about two years ago (Date: Wed, 18 Apr 2012 21:44:31 +0000 (UTC);
    I've gotten around to trying that. The problem is that apparently I
    had a different problem in mind than today's when I wrote
    With the method above, it's indeed transitive. (Also, if I leave out
    something from the INC path, it errors out at that "use" statement and
    doesn't check anything after. Our system does have a non-trivial
    include list.)

    For today's problem, I want only "directly", not "transitively".

    My group is adding calls subs in new modules and sometimes forgetting
    to add the "use" statements. Each of our modules should "use"
    everything it calls. I'd like a somewhat automated way to check
    statically for missing "use"s before we check in files. So I do not
    want transitive uses, and apparently we're doing a fair number of
    transitive "use"s.

    (I tried -d:Modlist as above with a library path that has only
    Devel::Modlist, but the problem above arises: since I'm leaving out
    many things from the INC path, it errors out at the first "use" of one
    of our modules and doesn't report anything after. And if I include our
    path, as aforesaid I get a lot of transitive uses that I don't want.)

    I'm thinking that I should just write a simple script to read a Perl
    file looking for
    - ^use foo::bar::baz
    save it as one of the uses (ignored any suffixed "nocritic", "no",
    or whatever)
    - foo::bar::baz->
    confirm that foo::bar::baz is in the hash of uses
    - foo::bar::baz::quux not followed by ->
    confirm that foo::bar::baz is in the hash of uses

    We very rarely do "require". We rarely do exports. So the above
    should work well enough 98% of the time. I'm OK with false positives
    in such odd cases, and false negatives (like calling an exported sub
    where you forgot to "use" the module directly) should be rare and you
    deserve the severe tire damage if you do it.

    Comments? Better ideas?
     
    Tim McDaniel, Mar 21, 2014
    #4
  5. (Tim McDaniel) writes:

    [...]
    This may not be applicable to your problem but what about maintaining a
    single list of use statements in a dedicated file?
     
    Rainer Weikusat, Mar 21, 2014
    #5
  6. Tim McDaniel

    Tim McDaniel Guest

    Reading and parsing the entire codebase when starting the program
    would take some time.
     
    Tim McDaniel, Mar 21, 2014
    #6
  7. Insofar use statements are being used to include modules, the entire
    codebase is 'read, parsed and compiled' prior to anything else
    happening:

    It is exactly equivalent to

    BEGIN { require Module; Module->import( LIST ); }
     
    Rainer Weikusat, Mar 21, 2014
    #7
  8. Tim McDaniel

    Tim McDaniel Guest

    I've been trying to think about this in the general case. The only
    objection I can think of is that a program might not directly or
    indirectly reach the entire codebase. There might be several
    programs, and different (perhaps overlapping, perhaps disjoint) parts
    of the codebase might be used by different programs. I think that
    condition obtains at my ork-place.

    The other objections I considered I don't think would actually be
    problems:
    - conflicting exports: they would have been happening before the "use
    unification"
    - ordering problems with BEGIN blocks: that's such a disaster of a
    design that I don't think it needs to be considered.

    Thank you for the idea and for prompting me to think under what
    conditions it might or might not be useful.
     
    Tim McDaniel, Mar 21, 2014
    #8
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Similar Threads
There are no similar threads yet.
Loading...