Skip Menu |
 

This queue is for tickets about the namespace-clean CPAN distribution.

Report information
The Basics
Id: 72368
Status: resolved
Priority: 0/
Queue: namespace-clean

People
Owner: Nobody in particular
Requestors: w.phillip.moore [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.21
Fixed in: 0.22



Subject: Applications using namespace::clean are implicitly dependent on Sub::Identify
Download (untitled) / with headers
text/plain 812b
I recently starting using a few large complex modules that happen to have namespace::clean in their dependency tree, and whenever I need to debug them, i find I need to first install Sub::Identify. I get burned because the automatic installation procedures like cpanp and friends will not install Sub::Identify when installing namespace::clean, since it is not listed as a dependency in the META.yml file, and Makefile.PL doesn't know about it either. The same is true for Sub::Name as well, of course. Is it unreasonable to request that both Sub::Name and Sub::Identify at least be defined as "recommends" dependencies, if not "requires"? You don't discover these modules are missing until the worst possible time: debugging a real problem in installed code (at least that's when I've been burned).
Download (untitled) / with headers
text/plain 694b
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
Subject: Re: [rt.cpan.org #72368] Applications using namespace::clean are implicitly dependent on Sub::Identify
Date: Sun, 13 Nov 2011 10:33:29 -0500
To: bug-namespace-clean [...] rt.cpan.org
From: Phillip Moore <w.phillip.moore [...] gmail.com>
Download (untitled) / with headers
text/plain 2.9k
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. 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: Show quoted text
> <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 >
Download (untitled) / with headers
text/plain 3.6k
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 > >
Download (untitled) / with headers
text/plain 898b
On Sun Nov 13 13:52:29 2011, SPROUT wrote: Show quoted text
> > Have you tried using Devel::Peek, which is part of core? > > So it doesn’t look as though namespace::autoclean needs to recommend > Sub::Identify at all. >
This is actually a namespace::clean ticket, not autoclean. In any case Sub::Identify is just a convenience wrapper, and is in fact pure-perl. In order to make the debugger happy however, one needs Sub::Name - and *that* is the problematic part at this point. While a pure-perl S::N concept was created and works, it still needs fleshing out before spilling on cpan. Since I attracted the attention of a venerable perlmonk, could you possibly look at another bug in this dist: https://rt.cpan.org/Ticket/Display.html?id=69862. It turns out that there is nobody with the knowledge of how to appease the debugger on 5.14+, hence the bug has been sitting unfixed for quite some time. Cheers
Download (untitled) / with headers
text/plain 105b
Sending the previous mail has failed. Please contact your admin, they can find more details in the logs.
Download (untitled) / with headers
text/plain 105b
Sending the previous mail has failed. Please contact your admin, they can find more details in the logs.
Download (untitled) / with headers
text/plain 988b
On Mon Nov 14 09:18:40 2011, RIBASUSHI wrote: Show quoted text
> On Sun Nov 13 13:52:29 2011, SPROUT wrote: >
> > > > Have you tried using Devel::Peek, which is part of core? > > > > So it doesn’t look as though namespace::autoclean needs to recommend > > Sub::Identify at all. > >
> > This is actually a namespace::clean ticket, not autoclean.
Oops, my mistake. Show quoted text
> In any case > Sub::Identify is just a convenience wrapper, and is in fact pure-perl. > In order to make the debugger happy however, one needs Sub::Name - and > *that* is the problematic part at this point.
I had assumed Philip Moore was trying to load it himself. I hadn’t realised namespace::clean itself was loading it. In trying to be helpful, I’ve just shown my ignorance. Show quoted text
> While a pure-perl S::N > concept was created and works,
I’d be fascinated to see how it works. It is using wrappers that goto &the_original? Does it have a separate :lvalue wrapper? Show quoted text
> it still needs fleshing out before > spilling on cpan.
Download (untitled) / with headers
text/plain 227b
Since the extra dependencies are now needed only on a range of perl versions (5.8.9 ~ 5.12.4), it seems a sensible middle ground to require these dependencies IFF a compiler toolchain is present. Thank you for bringing this up!


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.