On Sun Nov 13 10:33:39 2011, WPMOORE wrote:
Show quoted text> Fair points. I agree it doesn't need to be a "requires", which is why I
> suggested "recommends". I understand the grey areas around how these
> attributes are handled by the various toolchain utilities as well.
> Honestly, this type of dependency could easily be represented by a new
> keyword, too: debug_requires and debug_recommends. This would be a
> debug_requires, obviously. That's academic, though: I don't see the
> toolchain folks adding that without a long discussion. I should step up
> and join those discussions myself.
>
> In the environment I support, it is hard to install new dependencies on
> demand, once something has been deployed into the production environment.
> When you run into a production problem with packaged, deployed products,
> on machines that are locked down, you often can't install the missing
> software that easy, if at all. This is an issue for me in a very large
> (truly global) Enterprise environment, where things go through multiple
> stages of testing, qa, uat, whatever and then they get approved for prod.
> In development, it's trivial to satisfy the dependency, but my concern is
> what happens when things break in prod, and you want to leverage the
> debugger to figure out why.
>
> For me, personally, this is a moot point for this module, because now that
> I know namespace-clean has the dependency, I can manage this. I maintain
> my own superset of the CPAN metadata out of unfortunate necessity in order
> to make everything I do reproducible. This bit of missing metadata is an
> edge condition, really. Other than the optional dependencies the debugger
> has for implementing interactive readline functionality, this is the first
> time I've personally encountered a special debugger dependency.
Have you tried using Devel::Peek, which is part of core?
$ perl -MDevel::Peek -e '*foo = \&utf8::encode; Dump \&foo'
SV = RV(0x8039fc) at 0x8039f0
REFCNT = 1
FLAGS = (TEMP,ROK)
RV = 0x8040c0
SV = PVCV(0x824c18) at 0x8040c0
REFCNT = 3
FLAGS = ()
COMP_STASH = 0x0
XSUB = 0x11a310
XSUBANY = 0
GVGV::GV = 0x8040b0 "utf8" :: "encode"
FILE = "universal.c"
DEPTH = 0
FLAGS = 0x800
OUTSIDE_SEQ = 0
PADLIST = 0x0
OUTSIDE = 0x0 (null)
Look at the GVGV::GV line.
So it doesn’t look as though namespace::autoclean needs to recommend Sub::Identify at all.
Show quoted text> Couple
> that with the fact that the overwhelming majority of the developers I
> support don't seem to know HOW to really use the perl debugger, I'm
> probably one of the few here who cares :-P
>
> Anyway, it's your code, so it's your call. I have the problem solved
> locally (my own meta-metadata), and I appreciate the issues involved in
> making the judgment call. Thanks for considering it.
>
> On Sun, Nov 13, 2011 at 7:46 AM, Peter Rabbitson via RT <
> bug-namespace-clean@rt.cpan.org> wrote:
>
> > <URL:
https://rt.cpan.org/Ticket/Display.html?id=72368 >
> >
> > Your bug-title is misleading - an application is not "implicitly
> > dependent" on something if it prevents it from running in a debugger ;)
> >
> > A hard require is out by definition, since the whole point of recent
> > namespace::clean releases was to make it installable on gcc-less
> > machines (we do not yet have a pure-perl Sub::Name, and while I
> > eventually will get to it, it will be around "christmas").
> >
> > As far as recommends - I will need to get back to you on that, since
> > last I checked the toolchain was doing some strange stuff with this
> > piece of metadata.
> >
> > Also I am curious (without questioning your development practices) - why
> > is it hard for you to install the 2 extra modules on demand?
> >
> > Cheers
> >
