Skip Menu |

This queue is for tickets about the Devel-TraceUse CPAN distribution.

Report information
The Basics
Id: 65371
Status: open
Priority: 0/
Queue: Devel-TraceUse

People
Owner: Nobody in particular
Requestors: ribasushi [...] leporine.io
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)



Subject: Module does not treat base/parent specially
This sort of code is rather prevalent: package Foo; use base 'bar'; .... It reports 'bar' being use()d by base.pm which doesn't help with determining that it actually came from Foo. I think this module needs to treat base.pm and parent.pm in a special manner, given how the one and only purpose of these modules is to require other modules (also note that both of them are part of perl core) Cheers
Subject: Re: [rt.cpan.org #65371] Module does not treat base/parent specially
Date: Thu, 3 Feb 2011 02:02:08 +0100
To: Peter Rabbitson via RT <bug-Devel-TraceUse [...] rt.cpan.org>
From: "Philippe Bruhat (BooK)" <philippe.bruhat [...] free.fr>
On Wed, Feb 02, 2011 at 08:13:53AM -0500, Peter Rabbitson via RT wrote: Show quoted text
> > This sort of code is rather prevalent: > > package Foo; > use base 'bar'; > .... > > It reports 'bar' being use()d by base.pm which doesn't help with > determining that it actually came from Foo. > > I think this module needs to treat base.pm and parent.pm in a special > manner, given how the one and only purpose of these modules is to > require other modules (also note that both of them are part of perl core) >
Actually, this module is not about showing class hierarchies: it is about showing which code did the initial use/require call to load each module that ends up in %INC. For example, consider: $ perl -d:TraceUse -e 'package Bar;use base "Exporter";' Modules used from -e: 1. base 2.13, -e line 1 [Bar] 2. strict 1.04, base.pm line 3 3. vars 1.01, base.pm line 4 4. warnings::register 1.01, vars.pm line 7 5. warnings 1.06, warnings/register.pm line 24 6. Exporter 5.62, base.pm line 90 (eval 1) versus: $ perl -d:TraceUse -e 'use Exporter;package Bar;use base "Exporter";' Modules used from -e: 1. Exporter 5.62, -e line 1 [main] 2. base 2.13, -e line 1 [Bar] 3. strict 1.04, base.pm line 3 4. vars 1.01, base.pm line 4 5. warnings::register 1.01, vars.pm line 7 6. warnings 1.06, warnings/register.pm line 24 Also, each module loaded will only be reported once, when it was first loaded (except for load failures, where every attempt is recorded). Going back to your request: at first, I thought I could for example show the package from which base|parent was called, but even there, parent and base behave differently, and I have to look at different levels in the call stack to find the right package. Also, what about modules like 'relative' or 'Module::Pluggable', whose purpose is also to require other modules? -- Philippe Bruhat (BooK) One lesson learned is never enough. (Moral from Groo The Wanderer #104 (Epic))
Subject: Re: [rt.cpan.org #65371] Module does not treat base/parent specially
Date: Thu, 03 Feb 2011 10:52:20 +0100
To: bug-Devel-TraceUse [...] rt.cpan.org
From: Peter Rabbitson <ribasushi [...] cpan.org>
(Philippe 'BooK' Bruhat) via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=65371 > > > On Wed, Feb 02, 2011 at 08:13:53AM -0500, Peter Rabbitson via RT wrote:
>> This sort of code is rather prevalent: >> >> package Foo; >> use base 'bar'; >> .... >> >> It reports 'bar' being use()d by base.pm which doesn't help with >> determining that it actually came from Foo. >> >> I think this module needs to treat base.pm and parent.pm in a special >> manner, given how the one and only purpose of these modules is to >> require other modules (also note that both of them are part of perl core) >>
> > Actually, this module is not about showing class hierarchies: it is > about showing which code did the initial use/require call to load > each module that ends up in %INC.
Exactly! Show quoted text
> > For example, consider: > > $ perl -d:TraceUse -e 'package Bar;use base "Exporter";' > Modules used from -e: > 1. base 2.13, -e line 1 [Bar] > 2. strict 1.04, base.pm line 3 > 3. vars 1.01, base.pm line 4 > 4. warnings::register 1.01, vars.pm line 7 > 5. warnings 1.06, warnings/register.pm line 24 > 6. Exporter 5.62, base.pm line 90 (eval 1) > > versus: > > $ perl -d:TraceUse -e 'use Exporter;package Bar;use base "Exporter";' > Modules used from -e: > 1. Exporter 5.62, -e line 1 [main] > 2. base 2.13, -e line 1 [Bar] > 3. strict 1.04, base.pm line 3 > 4. vars 1.01, base.pm line 4 > 5. warnings::register 1.01, vars.pm line 7 > 6. warnings 1.06, warnings/register.pm line 24 > > Also, each module loaded will only be reported once, when it was first > loaded (except for load failures, where every attempt is recorded). >
Exactly :) Show quoted text
> Going back to your request: at first, I thought I could for example show > the package from which base|parent was called, but even there, parent > and base behave differently, and I have to look at different levels in > the call stack to find the right package.
perl -d:TraceUse -e 'package Foo; use base "File::Spec"; package Bar;use base "Exporter";' Modules used from -e: 1. base 2.15, -e line 1 [Foo] 2. strict 1.04, base.pm line 3 3. vars 1.01, base.pm line 4 4. warnings::register 1.01, vars.pm line 7 5. warnings 1.09, warnings/register.pm line 24 6. File::Spec 3.3101, base.pm line 91 (eval 2) 7. File::Spec::Unix 3.3, File/Spec.pm line 22 8. Exporter 5.64_01, base.pm line 91 (eval 5) This is a bad example but if it was broken into files, there'd be no way to determine who pulled Exporter in. Show quoted text
> Also, what about modules like 'relative' or 'Module::Pluggable', whose > purpose is also to require other modules?
There is only so much you can do. I was asking for a base/parent exception specifically because of their ubiquity. For example in an average DBIx::Class based project you will have twice the use base X calls, compared to use X Cheers
Subject: Re: [rt.cpan.org #65371] Module does not treat base/parent specially
Date: Tue, 8 Feb 2011 23:51:36 +0100
To: Peter Rabbitson via RT <bug-Devel-TraceUse [...] rt.cpan.org>
From: "Philippe Bruhat (BooK)" <philippe.bruhat [...] free.fr>
On Thu, Feb 03, 2011 at 04:52:35AM -0500, Peter Rabbitson via RT wrote: Show quoted text
>
> > Going back to your request: at first, I thought I could for example show > > the package from which base|parent was called, but even there, parent > > and base behave differently, and I have to look at different levels in > > the call stack to find the right package.
> > perl -d:TraceUse -e 'package Foo; use base "File::Spec"; package Bar;use base "Exporter";' > Modules used from -e: > 1. base 2.15, -e line 1 [Foo] > 2. strict 1.04, base.pm line 3 > 3. vars 1.01, base.pm line 4 > 4. warnings::register 1.01, vars.pm line 7 > 5. warnings 1.09, warnings/register.pm line 24 > 6. File::Spec 3.3101, base.pm line 91 (eval 2) > 7. File::Spec::Unix 3.3, File/Spec.pm line 22 > 8. Exporter 5.64_01, base.pm line 91 (eval 5) > > This is a bad example but if it was broken into files, there'd be no > way to determine who pulled Exporter in.
To make really useful information, I need to also differentiate between modules loaded by base.pm, but not via use base $module. See strict and vars in the above example. Well, the File::Spec and Export lines are eval lines... for base.pm. base does: eval "require $base"; parent does: require "$_.pm"; Show quoted text
> > Also, what about modules like 'relative' or 'Module::Pluggable', whose > > purpose is also to require other modules?
> > There is only so much you can do. I was asking for a base/parent > exception specifically because of their ubiquity. For example in > an average DBIx::Class based project you will have twice the > use base X calls, compared to use X
What about an easily extensible way of doing it: perl -d:TraceUse=proxy:base,proxy:parent -e 'package Foo; use base "File::Spec"; package Bar;use parent "Exporter";' which would consider base, parent and any other module you'd list here as a potential "proxy" module (one that loads other modules on your behalf), and would adapt the output to reflect this. Something like (made up output): Modules used from -e: 1. base 2.13, -e line 1 [Foo] *proxy* 2. strict 1.04, base.pm line 3 3. vars 1.01, base.pm line 4 4. warnings::register 1.01, vars.pm line 7 5. warnings 1.06, warnings/register.pm line 24 6. File::Spec 3.2501, base.pm line 90 (eval 1) <Foo> 7. File::Spec::Unix 3.2501, File/Spec.pm line 22 8. parent 0.223, -e line 1 [Bar] *proxy* 9. Exporter 5.62, parent.pm line 20 <Bar> Actually, I still need to find a way to differenciate between File::Spec and strict, since working up the call stack to find the package from which use base was called is probably not enough. -- Philippe Bruhat (BooK) Sometimes a setback can be the greatest form of progress. (Moral from Groo #6 (Image))

Hi.

 

I've made a hack fork thing which allows you to "ignore" certain packages in the load chain, and have a basic list of "known proxies" which can be useful to ignore.

I found this modification somewhat helpful, as it allowed me to rule out the sillyness it does where it implies  the first module to load base, thus, loads all the other modules that loads base.

ie:
 

28. Moo::_Utils, Moo.pm line 4
29. Sub::Name 0.05, Moo/_Utils.pm line 9
.... many lines of code
696. WWW::Shorten::generic 1.92, base.pm line 81 (eval 1576)
697. WWW::Shorten::UserAgent, WWW/Shorten/generic.pm line 26
698. LWP::UserAgent 6.05, base.pm line 81 (eval 1577)

Which suggests that Sub::Name loads LWP:: and friends, which is simply not true.


My modifications reveal the truth, that sub::name doesn't load any modules itself 99.999% of the time.  It loads 'base

Compare before; https://gist.github.com/kentfredric/dbd06989bd86aea698ca
and after: https://gist.github.com/kentfredric/77f80068cbc40da4f09b

The latter is actually useful for trying to weed out dependencies =)

https://github.com/kentfredric/Devel-TraceUse/compare/hide_proxies

Its not really written in a way that can easily be extended upon from the command line, but its still more useful than Devel::TraceUse is out of the box .