How do we know when a CORE module is deprecated?

I have edited this down to just the single real question.

08:57:05 < mst> cfedde: CGI.pm is deprecated and scheduled to be removed from
the core as a terrible idea by 5.22 at the latest


I check the module doc and I don't find a deprecation notice in it. Neither does there appear to be an "official CORE" deprecation list.

Is IRC where we go to find out that a module is deprecated?

16 Comments

Also, where to go to get perl5 advice that isn't insulting and rude? Yikes.

I don't believe that CGI.pm is "officially deprecated" though it is certainly discouraged. I know that SawyerX has given several talks entitled "CGI.pm must die" in which he uses strong language to humorous effect.

Though I wasn't involved in this chat, I want to apologize for the language used in the snippet you provided. It is appalling that in a community where we so often wonder how to increase the newcomer adoption of Perl, that someone would use that language describing a module which is commonly thought of as being a major part of Perl. No matter if we discourage its use or not, it IS a common entry point to Perl.

We in the know SHOULD push new users away from CGI.pm, but we should do it kindly, perhaps something like "CGI.pm is really old and we discourage its use, it is only still in the core because it is in wide use in legacy applications, but there are far better options."

I do something similar in my article "Learn to Spot a Good Tutorial". Good interaction is a key to keeping and bringing in new Perlers. I apologize again for some members of our community, this language is unnecessary not helpful.

CGI.pm is an important piece of Perl history and must be preserved.

Coke, Chris Fedde and apeiron have had an axe to grind against each other for years.

apeiron decided to put him on /ignore to avoid getting into any more non-constructive arguments.

cfedde apparently has gone the "passive aggressive blog post with out of context quotes" instead.

I wouldn't read too much into it; Shells, apeiron and I subsequently had a productive conversation and parted on good terms.

Ok, I wasn't aware of that mst, thanks for the context. Still new Perler wasanzy witnessed an exchange that might prevent him/her from seeking help in the future or worse, send him/her away from Perl. My apology stands, but now I target it to the onlookers.

It is not deprecated. I think mst misread an email from Ricardo Signes to the P5P list.

Joel, you still don't have any of the context for this, or the help that's been given to wasanzy over the previous weeks and months. I do, however, apologise to anybody who read this blog post before the author fixed it and got the wrong idea.

cfedde - thanks for ediiting your post.

I believe it's leaving core as of 5.22.0

'deprecated' is generally taken to mean "should be avoided because it's been superceded", which CGI.pm very definitely has as of the release of a Plack with CGI support.

Steven, it can be preserved on CPAN for the people with legacy code that requires it. Given the existence of Plack::Handler::CGI, starting a new project with CGI.pm in 2013 out of anything except ignorance is simply gross incompetence.

Still new Perler wasanzy witnessed an exchange that might prevent him/her from seeking help in the future or worse, send him/her away from Perl

Not just wasanzy, but everyone else who happened to be in #perl at that time.

"deprecated" has a specific meaning in the context of the perl core. It means that we have indicated that we may soon remove something from the core. For CPAN modules, we tend to deprecate something in release X and then remove it in release X+1. CGI.pm may be deprecated in 5.20, which would mean it would probably be removed from the core distribution in 5.22. This has not been begun in any official way.

You know when something has been deprecated because it will begin issuing a warning. For example, Switch.pm was deprecated in 5.12.0. If you used the Switch.pm installed with core perl, it would emit a warning saying "You're using a deprecated piece of core! Install it from the CPAN!" If you went ahead and did that, it would shut up.

The same thing is going on now with CPANPLUS and other libraries to be removed before 5.20.0

Deprecations are also listed clearly in perldelta documents, like perl5160delta. Search for "Deprecations" and "Future Deprecations" and "Deprecated Modules."

CGI.pm is now, if anything, more like discouraged, rather than deprecated. For clarification on how these two terms, see perldoc perlpolicy.

I've just started a CGI.pm-based project; not because I think CGI is great, but because I need to use a module that expects to be passed a blessed CGI object. Anybody know of a good way to mock one of them given $env?

So, presuming CGI.pm gets removed, does that mean Plack/PSGI gets added?

toby: CGI::PSGI->new($env) returns a CGI::PSGI object that isa CGI

CGI.pm is an important piece of Perl history and must be preserved.

An attempt at sarcasm. Epic fail, apparently :)

Petdance, anybody else who happened to be in #perl for the whole conversation will have seen:

wasanzy asked for help

Shells suggested something that's a really bad idea

apeiron corrected this

Shells, apeiron and I discussed it until Shells understood why it was a bad idea

We and various other channel members helped wasanzy find a good solution to their problem

As such, I'm reasonably confident that people wanting help writing good perl will not have been put off by the conversation.

We would vigorously oppose anybody suggesting that the solution to a missing 'my' declaration was to remove 'use strict'; CGI.pm is, compared to the alternatives that obsolete it, just as much of a bug source in the long run.

Leave a comment

About chris fedde

user-pic Chris has been building tomorrow's legacy systems for more than 2 decades. His favorite way of achieving this is through what he calls programming by research and find that perl and the CPAN provide a rich platform, ecosystem and community to succeed within.