I agree.
I think this should be pretty easy to accomplish. In sitecustomize.pl:
if ( $PERLDB ) {
require EFS::Perl::Debug;
}
In that Debug module:
if ( -d /efs/dist/perl5/$project/$perl_version ) {
# EPV incatation to use the above
}
Where $perl_version is 5.10.1, 5.12.1, etc? Do this for each of those extra
modules, of course.
Two things here: perhaps we should avoid English.pm in something so
ubiquitous, and what's the cheapest way to get the version?
This means that all you have to do to get readline support in the debugger
is use efsdeploy to install Term-ReadKey and Term-ReadLine-Perl, and create
a simple perl-version specific releasealias.
On Mon, Aug 2, 2010 at 3:27 PM, jerry gay <[email protected]>wrote:
> this text (below), lifted from EFS::Perl::Version, makes me wonder if
> we can modify the perl-core distro in such a way to make these two
> Term modules available *only* to perldb, to further limit their scope.
> i imagine it's possible and not too difficult with the hooks
> efs-deploy has available, but is it worth it? in my current boot.efs
> setup, i don't have the Term:: modules installed, and using the
> debugger is less than ideal. i'll fix that manually now that i've
> seen what i'm missing, but i'm left with the question above, because
> the current solution still allows possibility of conflict with any
> code that expects a different version of these modules. limiting the
> visibility of the "default" modules available in the perl core to the
> smallest possible scope makes sense, in that it limits conflict
> further--especially as we consider other efs users, who may use these
> Term:: modules more frequently or heavily than our current clients do,
> and may increase the possibility of version conflicts.
>
> so, how would we do it? a sitecustomize.pl hack means every time perl
> runs it would need to pay overhead to check if the debugger is
> running. i'm not sure how much info we have on that when
> sitecustomize.pl runs--probably enough, but unknown. an @INC closure
> that does the checking is another possibility. this runs every time
> perl does, too, but later in the startup process than does
> sitecustomize.pl. actually, it runs every time a perl module is used,
> which means more than once per script being loaded. this makes me
> think sitecustomize.pl would be the better way to go, to reduce
> overhead. there are more nefarious means of getting this to work, but
> how far into perl's internals do we want to poke? i say, "not far".
>
> this isn't high priority by any means, but it's worth considering as
> we're bootstrapping perl-core in efs 3.
>
> EPV text below:
>
>
> The only "default" modules made available are those in the perl core
> itself (which change only when the perl core changes), or a few
> utility modules which are exceptions to the rule. One such exception
> is this module (EFS::Perl::Version). The only other non-core modules
> we recommend making visible by default are:
>
> Term::ReadLine::Gnu
> Term::ReadKey
> _______________________________________________
> EFS-dev mailing list
> [email protected]
> http://mailman.openefs.org/mailman/listinfo/efs-dev
>
_______________________________________________
EFS-dev mailing list
[email protected]
http://mailman.openefs.org/mailman/listinfo/efs-dev
