FAQ
A recent discussion has come up in the RT queue for Locale::Codes concerning what the install destination for dual core modules should be. If the module is not deprecated, is there any documentation on where CPAN installed dual core modules are supposed to install to?

If not, has there been any consistent policy and/or does cpan/cpanplus do any magic to make sure there is only one copy of dual core modules in the perl lib trees?

Thanks,
Todd

https://rt.cpan.org/Public/Bug/Display.html?id=54526

Search Discussions

  • Curtis Jewell at Feb 12, 2010 at 7:13 pm

    On Fri, 12 Feb 2010 12:16 -0600, "Todd Rinaldo" wrote:
    A recent discussion has come up in the RT queue for Locale::Codes
    concerning what the install destination for dual core modules should be.
    If the module is not deprecated, is there any documentation on where CPAN
    installed dual core modules are supposed to install to?
    My understanding (no particular documentation that I know of - maybe
    there should be) is that they install to 'core', not to 'site', unless
    deprecated , or they aren't in core yet. (in which case, it's the other
    way around.)
    If not, has there been any consistent policy and/or does cpan/cpanplus do
    any magic to make sure there is only one copy of dual core modules in the
    perl lib trees?

    Thanks,
    Todd

    https://rt.cpan.org/Public/Bug/Display.html?id=54526
    --Curtis
    --
    Curtis Jewell
    csjewell@cpan.org http://csjewell.dreamwidth.org/
    perl@csjewell.fastmail.us http://csjewell.comyr.org/perl/

    "Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c

    Strawberry Perl for Windows betas: http://strawberryperl.com/beta/
  • Jerry D. Hedden at Feb 12, 2010 at 8:45 pm
    With 5.11, the order of @INC has been changed to put 'site_perl' in
    the 'front' of the array. This means that for dual-lived modules, the
    'core' version is in 'perl', and if it is update from CPAN, the CPAN
    version will 'mask it' when it gets installed in 'site_perl'. In this
    way, the 'core' stays unperturbed even if modules are updated.

    Hence, Makefile.PL (or whatever) needs to have the following construct
    for dual-lived modules:

    INSTALLDIRS => ((($] >= 5.???) || ($] < 5.011)) ? 'perl' : 'site'),

    Where the lower version number is when the module was first introduced
    into 'core' (as per Corelist.pm).

    On Fri, Feb 12, 2010 at 14:12, Curtis Jewell
    wrote:
    On Fri, 12 Feb 2010 12:16 -0600, "Todd Rinaldo" wrote:
    A recent discussion has come up in the RT queue for Locale::Codes
    concerning what the install destination for dual core modules should be.
    If the module is not deprecated, is there any documentation on where CPAN
    installed dual core modules are supposed to install to?
    My understanding (no particular documentation that I know of - maybe
    there should be) is that they install to 'core', not to 'site', unless
    deprecated , or they aren't in core yet. (in which case, it's the other
    way around.)
    If not, has there been any consistent policy and/or does cpan/cpanplus do
    any magic to make sure there is only one copy of dual core modules in the
    perl lib trees?

    Thanks,
    Todd

    https://rt.cpan.org/Public/Bug/Display.html?id=54526
    --Curtis
    --
    Curtis Jewell
    csjewell@cpan.org           http://csjewell.dreamwidth.org/
    perl@csjewell.fastmail.us   http://csjewell.comyr.org/perl/

    "Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c

    Strawberry Perl for Windows betas: http://strawberryperl.com/beta/
  • David Golden at Feb 12, 2010 at 8:55 pm

    On Fri, Feb 12, 2010 at 3:44 PM, Jerry D. Hedden wrote:
    With 5.11, the order of @INC has been changed to put 'site_perl' in
    the 'front' of the array.  This means that for dual-lived modules, the
    'core' version is in 'perl', and if it is update from CPAN, the CPAN
    version will 'mask it' when it gets installed in 'site_perl'.  In this
    way, the 'core' stays unperturbed even if modules are updated.
    With the usual caveat that "UNINST=1" or "--uninst=1" (EU::MM and
    M::B) respectively will delete rather than mask, if the user has
    permissions to do so.

    -- David
  • Todd Rinaldo at Feb 12, 2010 at 11:19 pm

    On Feb 12, 2010, at 2:44 PM, Jerry D. Hedden wrote:

    With 5.11, the order of @INC has been changed to put 'site_perl' in
    the 'front' of the array. This means that for dual-lived modules, the
    'core' version is in 'perl', and if it is update from CPAN, the CPAN
    version will 'mask it' when it gets installed in 'site_perl'. In this
    way, the 'core' stays unperturbed even if modules are updated.

    Hence, Makefile.PL (or whatever) needs to have the following construct
    for dual-lived modules:

    INSTALLDIRS => ((($] >= 5.???) || ($] < 5.011)) ? 'perl' : 'site'),

    Where the lower version number is when the module was first introduced
    into 'core' (as per Corelist.pm).
    I'll start my reply by applauding who ever got site_lib put at the front of @INC. I'm glad to see this change.

    I definitely think this is a game changer. Now the CPAN versions of dual core modules don't have to write to the same library tree that core installs to. This solves the packaging nightmare: overwriting files distributed with another package without conflicting with the other package.

    I am however concerned that changing @INC is only half of the problem. We've got 100+ dual core modules that may need to change their Makefile.PL/Build.PL to cope with this change. And since there is no well known documentation on the topic, chances are even if we got them cleaned up, INSTALLDIRS => 'perl' is probably in other modules just out of ignorance. It occurs to me that with this change, there is no longer a good reason that someone generating an install running Build.PL or Makefile.PL without arguments should generate an install to core path. It seems like EUMM and M::B would do well to ignore INSTALLDIRS if $] >= 5.011. Both installers could flip a warning message if they intend to ignore INSTALLDIRS with some sort of "notify the author/here's how you override me if you insist on installing into perl core directories" message.

    As insane as this idea might sound initially, I'd like to hear p5p's take on the idea.
  • David Golden at Feb 14, 2010 at 12:57 am

    On Fri, Feb 12, 2010 at 6:19 PM, Todd Rinaldo wrote:

    It seems like EUMM and M::B would do well to ignore INSTALLDIRS if $] >= 5.011. Both installers could flip a warning message if they intend to ignore INSTALLDIRS with some sort of "notify the author/here's how you override me if you insist on installing into perl core directories" message.

    As insane as this idea might sound initially, I'd like to hear p5p's take on the idea.
    ^^^^^^

    There are so many ways that could go wrong.

    It would make more sense to try to control that via CPAN(PLUS) and
    have them explicitly provide correct INSTALLDIRS, overriding whatever
    might be in the Makefile.PL/Build.PL.

    Unfortunately: code freeze. So that will have to wait until 5.14
    unless Jesse thinks this is a blocker and can get people (not
    including me) to patch CPAN(PLUS).

    -- David

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedFeb 12, '10 at 6:16p
activeFeb 14, '10 at 12:57a
posts6
users4
websiteperl.org

People

Translate

site design / logo © 2021 Grokbase