bulknews.typepad.com

cpanm 1.3 will disable --uninst-shadows by default for perl >= 5.12

This is more of a note to self than an announcement.

cpanminus 1.3 will be released soon, with just one fix - it will disable the --unint-shadows option by default if your perl is newer than 5.12.

Uninstalling shadow module files has been only necessary when you upgrade core modules that gets installed to 'site' library path, or upgrade modules that once has been implemented in XS but switched to pure perl. Because perl prior to 5.12 had its perl library path before site_perl, you have to remove those shadows in perl path, so that the updated one can be picked up.

Perl 5.12 fixed this problem by reorganizing the library include path: site_perl path now comes before the core perl path, so you actually don't need to remove the shadows. Removing those files now do more harm than good, with the awesome cpanm's -L (--local-lib-contained) option, since now you have one module in core 'perl' directory while those dependencies are installed into 'site' - so when you try to isolate perl's "core-only" perl environment, you have a broken installation such as Module::Build.

Disabling uninst-shadows is not a complete solution to this either. This keeps the copy of modules that come with perl in 'perl' directory, while modules that get installed into 'perl' still get updated inside 'perl', which makes it hard for cpanm -L to work properly.

We may need to be able to have a way to isolate the "virgin perl" library path by probably copying the files once you install a fresh perl with tools like perlbrew.

The alternative is to not use lib::core::only as a way to figure out the core module dependency, and instead use Module::CoreList as a dictionary, which has the benefit of being able to say "installs non-core modules for 5.8.x" even if you build on, say, perl 5.13 which has more core modules than previous versions.

FindBin, __FILE__, $0 and PSGI woes

tl;dr: Do not use if (__FILE__ eq $0) in your .psgi code, that's not supposed to work since Plack 0.9971.

There's been a known issue in Starman and Plack based Perl web servers in general, where FindBin module used in your application doesn't return an expected value.

To make things even worse with Starman, when it hits the --max-requests and tries to restart the worker, it eventually crashes the process because the FindBin module can't even find the value of $0 and gets confused.

Today, after a quick discussion around this too frequently asked issues on the #plack IRC channel, I added a very simple commit that localizes the value of $0 to the path of .psgi file. It seems to solve those issues nicely: the use of FindBin correctly returns the expected path of .psgi file, and Starman doesn't crash when restarting.

However it turns out (thanks to clkao for the heads up), there're lots of .psgi files in the wild that has the following idiom, including my own scripts:

my $app = sub { ... };

if (__FILE__ eq $0) { 
    # called from the command line
    run_server_with($app);
} else {
    # called from PSGI web servers
    return $app;
}

It basically checks if __FILE__ is the same value as $0 and if it is so, consider that the .psgi (or .pl) script is being run from the command line, and try to launch the application with a server using modules like Plack::Runner. And the commit in question (already shipped as 0.9971 on CPAN) breaks this assumption.

The quick workaround we can think of are the use of other conditions, such as:

# PLACK_ENV is set by plackup etc.
unless ($ENV{PLACK_ENV}) { ... }

# caller is set if .psgi is evaluated
unless (caller) { ... }

# when Plack::Util::load_psgi() is called, package is automatically mangled
# similar to the Python equivalent idiom
if (__PACKAGE__ eq 'main') { ... }

I'm not 100% sure yet, whether it's better to revert the change, or to recommend everyone to stop using the if ($0 eq __FILE__) idiom in .psgi scripts and switch to one of these other conditions.

If you suffer from this bug, my apologies. You can either revert to earlier Plack release, or switch to one of those suggested other conditions, since they're meant to be safer and don't get affected by the $0 change.

If you have a really strong opinion that we should revert the change, chime in on a comment or on the irc channel #plack on irc.perl.org.

UPDATE: After another round of discussion, we agreed that this is a good change, and 0.9972 added a quick check in the development environment to see if your .psgi file contains that idiom (with a regular expression :)) to give you a warning in that case.