Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Since we don't have a decent API versioning scheme, it often feels like the right thing to do is to change the namespace when you're making a change that will nontrivially break backcompat.

    Amongst my other complaints:

    Deprecation does not equal deletion.

    In computer software standards and documentation, the term deprecation is applied to software features that are superseded and should be avoided. Although deprecated features remain in the current version, their use may raise warning messages recommending alternate practices, and deprecation may indicate that the feature will be removed in the future. Features are deprecated—rather than being removed—in order to provide backward compatibility and give programmers using the feature time to bring their code into compliance with the new standard.
    (From that wikipedia place, but I swear I didn't edit it just to make a point. The emphasis is mine, though [wikipedia.org])

    Adam's gone and backed out the removal of the feature, so this is temporarily a non-issue. But when you deprecate an API, it's _supposed to keep working_ during a transition period.

    If the feature does end up getting redeleted, having Module::Install just stop working if there's an auto_install directive in a Makefile.PL seems like a really bad choice that's likely to hurt the less savvy users that auto_install was there to help in the first place. If the intent is that the feature is both broken and unneeded if the end-user is following best practices, make M::I smart enough to say "Hey! The author of this Makefile.PL did something that's no longer supported. I've dealt with it for you" rather than: sub auto_install { die 'Module::Install::AutoInstall often breaks CPAN and has been deprecated'; } That's the kind of thing that reenforces the unfortunate "CPAN is an unusable nightmare" meme.

    • In my defense, the command has been DOCUMENTED as deprecated for some time.

      As Matt pointed out though, nobody reads the documentation.

      Further, please let me be clear to everyone that Module::Install is NOT like other parts of the toolchain.

      If I remove auto_install from Module::Install, it DOESN'T impact end users (the people installing modules) at all.

      Existing modules with auto_install in them will continue to work exactly the same and don't break. This was the entire principle behind Module::Install in the
      • Where has the deprecation been documented?

        As of 0.68, auto_install is part of the _recommended_ usage in my copy of Module/Install.pod

        You say: "If I remove auto_install from Module::Install, it DOESN'T impact end users (the people installing modules) at all."

        That's true for people installing from CPAN, but it's plenty common for people to check things out of subversion repositories or otherwise end up with a Makefile.PL that uses Module::Install and end up regenerating inc, but yes, I acknowledge that this