develooper Front page | perl.perl5.porters | Postings from June 2012

Re: for inclusion in core: Config::Perl::V

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
June 18, 2012 10:50
Subject:
Re: for inclusion in core: Config::Perl::V
Message ID:
20120618175046.GK9069@plum.flirble.org
On Mon, Jun 18, 2012 at 01:39:30PM -0400, Ricardo Signes wrote:
> 
> It is very likely that Config::Perl::V, used by a number of smoking libraries
> to get information about the running perl, is going to go into core.
> 
>   https://metacpan.org/module/Config::Perl::V
> 
> Cheers, comments, and objections would be appropriate at this time.

I wasn't aware of this plan.

I see that the implementation is this:

sub myconfig
{
    my $args = shift;
    my %args = ref $args eq "HASH"  ? %$args :
               ref $args eq "ARRAY" ? @$args : ();

    #y $pv = qx[$^X -e"sub Config::myconfig{};" -V];
    my $pv = qx[$^X -V];
       $pv =~ s{.*?\n\n}{}s;
       $pv =~ s{\n(?:  \s+|\t\s*)}{ }g;

    #print $pv;

    my $build = { %empty_build };
    $pv =~ m{^\s+Built under (.*)}m                and $build->{osname} = $1;
    $pv =~ m{^\s+Compiled at (.*)}m                and $build->{stamp}  = $1;
    $pv =~ m{^\s+Locally applied patches:\s+(.*)}m and $build->{patches} = [ split m/\s+/, $1 ];
    $pv =~ m{^\s+Compile-time options:\s+(.*)}m    and map { $build->{options}{$_} = 1 } split m/\s+/, $1;

    my @KEYS = keys %ENV;
    my %env  =
	map {      $_ => $ENV{$_} } grep m/^PERL/      => @KEYS;
    $args{env} and
	map { $env{$_} = $ENV{$_} } grep m{$args{env}} => @KEYS;

    my %config = map { $_ => $Config{$_} } @config_vars;

    return _make_derived ({
	build		=> $build,
	environment	=> \%env,
	config		=> \%config,
	derived		=> {},
	inc		=> \@INC,
	});
    } # myconfig



I'm fine with the API this presents.

But for current and future perls, I *really* don't think that we should be
adding a module that shells out to the current Perl. The entire output of
perl -V is now generated *in Perl space* by Config::_V. Most of the values
needed already exposed by public subroutines in Config, such as
Config::compile_date(). I think that the correct approach is to expose
whatever else is needed, and have Config::Perl::V avoid shelling out if it
doesn't need to.

The reason I strenuously object to shelling out back to $^X is not
theoretical.  It can cause strange bugs. It certainly breaks things like
profiling when they are invoked via environment variables.

(Been there, wasted a lot of time figuring it it out - the shelled out process
is *also* profiled, and that truncates the profiling output file if a fixed
filename is used, which is the usual default)


So I don't think that the module should go in until it and blead together
are capable of producing the correct output without needing to run any
sub-processes.

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About