From @rjbs

We have been working (slowwwly) for years to remove Pod​::Parser from the core
perl distribution. At this point, I believe the only blocker is Pod​::Checker.
Pod​::Checker is waiting to be converted through the application of this patch​:

  https://rt.cpan.org/Ticket/Display.html?id=85442

Once that is done, we will need to update the known problems file for the
podchecker test and we can add "use deprecate" to Pod​::Parser. (Or so I
think.)

That should get done by perl 5.20 so we can fully remove Pod​::Parser in perl
5.22.

--
rjbs

From @rjbs

In the event that we are unable to get patches into Pod​::Checker to switch it to Pod​::Simple, we
will have to consider ejecting Pod​::Checker and renaming the Pod​::Checker-with-Pod​::Simple
branch into Pod​::Simple​::Checker, or something of the sort, in order to move forward with this. I
would rather not have it come to that.

--
rjbs

@rjbs - Status changed from 'new' to 'open'

From @cpansprout

On Mon Sep 02 19​:50​:21 2013, rjbs wrote​:

In the event that we are unable to get patches into Pod​::Checker to
switch it to Pod​::Simple, we
will have to consider ejecting Pod​::Checker and renaming the
Pod​::Checker-with-Pod​::Simple
branch into Pod​::Simple​::Checker, or something of the sort, in order
to move forward with this. I
would rather not have it come to that.

You say ‘we will have to’, but is Pod​::Parser really that bad that we
have to take measures that would be confusing to users?

In other words, why go to great lengths to remove it from core when that
time could be spent fixing core bugs? :-)

--

Father Chrysostomos

From @rjbs

On Mon Sep 02 21​:36​:26 2013, sprout wrote​:

On Mon Sep 02 19​:50​:21 2013, rjbs wrote​:

In the event that we are unable to get patches into Pod​::Checker to
switch it to Pod​::Simple, we
will have to consider ejecting Pod​::Checker and renaming the
Pod​::Checker-with-Pod​::Simple
branch into Pod​::Simple​::Checker, or something of the sort, in order
to move forward with this. I
would rather not have it come to that.

You say ‘we will have to’, but is Pod​::Parser really that bad that we
have to take measures that would be confusing to users?

You left out the word after "to," which was "consider."

We can worry about whether it's that bad or that hard to do once we're forced to consider. For
now, it is only a worry on the horizon.

--
rjbs

From @cpansprout

On Tue Sep 03 06​:10​:46 2013, rjbs wrote​:

On Mon Sep 02 21​:36​:26 2013, sprout wrote​:

On Mon Sep 02 19​:50​:21 2013, rjbs wrote​:

In the event that we are unable to get patches into Pod​::Checker
to
switch it to Pod​::Simple, we
will have to consider ejecting Pod​::Checker and renaming the
Pod​::Checker-with-Pod​::Simple
branch into Pod​::Simple​::Checker, or something of the sort, in
order
to move forward with this. I
would rather not have it come to that.

You say ‘we will have to’, but is Pod​::Parser really that bad that
we
have to take measures that would be confusing to users?

You left out the word after "to," which was "consider."

We can worry about whether it's that bad or that hard to do once we're
forced to consider. For
now, it is only a worry on the horizon.

Yes, sorry, I did misread it. But my response was only meant to be
tongue-in-cheek. :-)

--

Father Chrysostomos

From @xdg

On Thu, Aug 22, 2013 at 10​:25 PM, Ricardo SIGNES
<perlbug-followup@​perl.org> wrote​:

We have been working (slowwwly) for years to remove Pod​::Parser from the core
perl distribution. At this point, I believe the only blocker is Pod​::Checker.
Pod​::Checker is waiting to be converted through the application of this patch​:

https://rt.cpan.org/Ticket/Display.html?id=85442

We're blocked on a patch not being applied since May? :-(

I suggest setting a hard deadline for application of the patch and
release to CPAN with the alternative being that a volunteer co-maint
will then be found and granted permissions to make it happen.

(I nominate mst to handle volunteer/PAUSE wrangling, given his talents
at both. :-)

David

--
David Golden <xdg@​xdg.me>
Take back your inbox! → http​://www.bunchmail.com/
Twitter/IRC​: @​xdg

From @jkeenan

On Tue Sep 03 09​:43​:17 2013, xdg@​xdg.me wrote​:

On Thu, Aug 22, 2013 at 10​:25 PM, Ricardo SIGNES
<perlbug-followup@​perl.org> wrote​:

We have been working (slowwwly) for years to remove Pod​::Parser from
the core
perl distribution. At this point, I believe the only blocker is
Pod​::Checker.
Pod​::Checker is waiting to be converted through the application of
this patch​:

https://rt.cpan.org/Ticket/Display.html?id=85442

We're blocked on a patch not being applied since May? :-(

This indicates that CPAN #85442 has been marked Resolved​:

https://rt.cpan.org/Public/Bug/Display.html?id=85442#txn-1265804

What are the next steps needed for this RT?

Thank you very much.
Jim Keenan

From @rjbs

On Tue Feb 18 18​:39​:52 2014, jkeenan wrote​:

What are the next steps needed for this RT?

The new Pod​::Checker emits different strings for the errors it finds, based on Pod​::Simple rather than Pod​::Parser's warnings. Our pod exceptions (the known errors file) must be updated.

Our podcheck test adds some tests of its own, written toward Pod​::Parser rather than Pod​::Simple. Those tests need updating.

Unless someone on a white horse rides in (please oh please), I will probably be doing this work at the QA Hackathon.

--
rjbs

From gottreu@gmail.com

On Feb 18, 2014 8​:58 PM, "Ricardo SIGNES via RT" <perlbug-followup@​perl.org>
wrote​:

The new Pod​::Checker emits different strings for the errors it finds,
based on Pod​::Simple rather than Pod​::Parser's warnings. Our pod
exceptions (the known errors file) must be updated.

Our podcheck test adds some tests of its own, written toward Pod​::Parser
rather than Pod​::Simple. Those tests need updating.

Unless someone on a white horse rides in (please oh please), I will
probably be doing this work at the QA Hackathon.

As I haven't seen any horses, I will take a swing at this.

From @rjbs

* Brian Gottreu <gottreu@​gmail.com> [2014-02-24T16​:33​:00]

As I haven't seen any horses, I will take a swing at this.

You will win my thanks, and a round of tacos and drinks.

--
rjbs

From @khwilliamson

On 2/24/2014 6​:49 PM, Ricardo Signes wrote​:

* Brian Gottreu <gottreu@​gmail.com> [2014-02-24T16​:33​:00]

As I haven't seen any horses, I will take a swing at this.

You will win my thanks, and a round of tacos and drinks.

There is a version of podcheck that I thought rjbs was using that I
thought was updated to use these; it certainly was updated to work with
Marc Green's changes

From gottreu@gmail.com

Version 1.70 of Pod​::Checker removed the 'hyperlink' method which podcheck.t uses. Where should that required functionality go? Back in to Pod​::Checker without using Pod​::Hyperlink (or whatever caused the removal), into podcheck.t, or even up into Pod​::Simple?

From @rjbs

* Brian Gottreu via RT <perlbug-followup@​perl.org> [2014-03-05T01​:13​:29]

Version 1.70 of Pod​::Checker removed the 'hyperlink' method which podcheck.t
uses. Where should that required functionality go? Back in to Pod​::Checker
without using Pod​::Hyperlink (or whatever caused the removal), into
podcheck.t, or even up into Pod​::Simple?

I suggest putting it in podcheck.t for now. If it turns out that it seems
generally useful, it can be ported upward later.

--
rjbs

From @tonycoz

On Tue Mar 04 22​:13​:29 2014, gottreu wrote​:

Version 1.70 of Pod​::Checker removed the 'hyperlink' method which
podcheck.t uses. Where should that required functionality go? Back
in to Pod​::Checker without using Pod​::Hyperlink (or whatever caused
the removal), into podcheck.t, or even up into Pod​::Simple?

Hi Brian,

Have you had time to work on this?

Otherwise I'll take a poke at it.

Tony

From @Smylers

Ricardo SIGNES writes​:

We have been working (slowwwly) for years to remove Pod​::Parser from
the core perl distribution. At this point, I believe the only blocker
is Pod​::Checker.

Karl Williamson has heroically achieved this (in RT #116467).

However, perlpodspec is still promoting Pod​::Parser in a couple of
places. Would readers be better served by being pointed at Pod​::Simple
instead?

This one can be addressed by simply changing the module name​:

  Authors of Pod formatters/processors should make every effort to avoid
  writing their own Pod parser. There are already several in CPAN, with
  a wide range of interface styles -- and one of them, Pod​::Parser,
  comes with modern versions of Perl.

But this one is trickier​:

  In parsing Pod, a notably tricky part is the correct parsing of
  (potentially nested!) formatting codes. Implementors should consult
  the code in the "parse_text" routine in Pod​::Parser as an example of a
  correct implementation.

What's the equivalent place in Pod​::Simple that would serve as an
example of how to get this right?

Smylers
--
http​://twitter.com/Smylers2

From @khwilliamson

On 05/31/2016 07​:30 AM, Smylers wrote​:

Ricardo SIGNES writes​:

We have been working (slowwwly) for years to remove Pod​::Parser from
the core perl distribution. At this point, I believe the only blocker
is Pod​::Checker.

Karl Williamson has heroically achieved this (in RT #116467).

However, perlpodspec is still promoting Pod​::Parser in a couple of
places. Would readers be better served by being pointed at Pod​::Simple
instead?

Good catch

This one can be addressed by simply changing the module name​:

Authors of Pod formatters/processors should make every effort to avoid
writing their own Pod parser. There are already several in CPAN, with
a wide range of interface styles -- and one of them, Pod​::Parser,
comes with modern versions of Perl.

Would you like to submit a patch for this? If so, I guarantee it will
get applied.

But this one is trickier​:

In parsing Pod, a notably tricky part is the correct parsing of
(potentially nested!) formatting codes. Implementors should consult
the code in the "parse_text" routine in Pod​::Parser as an example of a
correct implementation.

What's the equivalent place in Pod​::Simple that would serve as an
example of how to get this right?

This one is tricky because the code in Pod​::Simple/BlackBox.pm that
mostly deals with this have various comments in it like​:

# Are you really sure you want to read this code?
# - - - Turn back now! Run away! - - -
## stop reading now stop reading now stop reading now stop reading now stop
##
## HERE IT BECOMES REALLY SCARY
##
## stop reading now stop reading now stop reading now stop reading now stop

So I don't know, I'd be ok with leaving the Pod​::Parser reference in
here (though I have never looked at its code actually)

Smylers

From @khwilliamson

On Tue, 31 May 2016 09​:56​:37 -0700, public@​khwilliamson.com wrote​:

On 05/31/2016 07​:30 AM, Smylers wrote​:

Ricardo SIGNES writes​:

We have been working (slowwwly) for years to remove Pod​::Parser from
the core perl distribution. At this point, I believe the only blocker
is Pod​::Checker.

Karl Williamson has heroically achieved this (in RT #116467).

However, perlpodspec is still promoting Pod​::Parser in a couple of
places. Would readers be better served by being pointed at Pod​::Simple
instead?

Good catch

This one can be addressed by simply changing the module name​:

Authors of Pod formatters/processors should make every effort to avoid
writing their own Pod parser. There are already several in CPAN, with
a wide range of interface styles -- and one of them, Pod​::Parser,
comes with modern versions of Perl.

Would you like to submit a patch for this? If so, I guarantee it will
get applied.

But this one is trickier​:

In parsing Pod, a notably tricky part is the correct parsing of
(potentially nested!) formatting codes. Implementors should consult
the code in the "parse_text" routine in Pod​::Parser as an example of a
correct implementation.

What's the equivalent place in Pod​::Simple that would serve as an
example of how to get this right?

This one is tricky because the code in Pod​::Simple/BlackBox.pm that
mostly deals with this have various comments in it like​:

# Are you really sure you want to read this code?
# - - - Turn back now! Run away! - - -
## stop reading now stop reading now stop reading now stop reading now stop
##
## HERE IT BECOMES REALLY SCARY
##
## stop reading now stop reading now stop reading now stop reading now stop

So I don't know, I'd be ok with leaving the Pod​::Parser reference in
here (though I have never looked at its code actually)

Smylers

In lieu of a patch from Smylers, I pushed one myself for the first reference to Pod​::Parser in perlpodspec as 67e5e059984f24c6c80a0f8278e40ce418d15c8b. I left the reference in that said to refer to it if you're writing a replacement. This is because of the comments in Pod​::Simple that are designed to scare people away.

Pod​::Parser will not be removed in 5.26, as there is still a dependency on it. So, I'm moving this ticket to block 5.28 instead. The dependency is that it is the only way to extract just the pod from a larger file. I made significant headway in reimplementing that in Pod​::Simple, but shelved it to work on higher priority things for 5.26. I intend to finish it up once 5.26 is in code freeze.

--
Karl Williamson

From @jkeenan

On Mon, 09 Jan 2017 05​:47​:27 GMT, khw wrote​:

On Tue, 31 May 2016 09​:56​:37 -0700, public@​khwilliamson.com wrote​:

On 05/31/2016 07​:30 AM, Smylers wrote​:

Ricardo SIGNES writes​:

We have been working (slowwwly) for years to remove Pod​::Parser
from
the core perl distribution. At this point, I believe the only
blocker
is Pod​::Checker.

Karl Williamson has heroically achieved this (in RT #116467).

However, perlpodspec is still promoting Pod​::Parser in a couple of
places. Would readers be better served by being pointed at
Pod​::Simple
instead?

Good catch

This one can be addressed by simply changing the module name​:

Authors of Pod formatters/processors should make every effort to
avoid
writing their own Pod parser. There are already several in CPAN,
with
a wide range of interface styles -- and one of them, Pod​::Parser,
comes with modern versions of Perl.

Would you like to submit a patch for this? If so, I guarantee it
will
get applied.

But this one is trickier​:

In parsing Pod, a notably tricky part is the correct parsing of
(potentially nested!) formatting codes. Implementors should
consult
the code in the "parse_text" routine in Pod​::Parser as an example
of a
correct implementation.

What's the equivalent place in Pod​::Simple that would serve as an
example of how to get this right?

This one is tricky because the code in Pod​::Simple/BlackBox.pm that
mostly deals with this have various comments in it like​:

# Are you really sure you want to read this code?
# - - - Turn back now! Run away! - - -
## stop reading now stop reading now stop reading now stop reading
now stop
##
## HERE IT BECOMES REALLY SCARY
##
## stop reading now stop reading now stop reading now stop reading
now stop

So I don't know, I'd be ok with leaving the Pod​::Parser reference in
here (though I have never looked at its code actually)

Smylers

In lieu of a patch from Smylers, I pushed one myself for the first
reference to Pod​::Parser in perlpodspec as
67e5e059984f24c6c80a0f8278e40ce418d15c8b. I left the reference in
that said to refer to it if you're writing a replacement. This is
because of the comments in Pod​::Simple that are designed to scare
people away.

Pod​::Parser will not be removed in 5.26, as there is still a
dependency on it. So, I'm moving this ticket to block 5.28 instead.
The dependency is that it is the only way to extract just the pod from
a larger file. I made significant headway in reimplementing that in
Pod​::Simple, but shelved it to work on higher priority things for
5.26. I intend to finish it up once 5.26 is in code freeze.

Karl, do you have a battle plan for the removal of Pod-Parser from core now that 5.26.0 is out the door?

Are there parts that could be delegated to other people?

Thank you very much.
--
James E Keenan (jkeenan@​cpan.org)

From @khwilliamson

On 06/01/2017 07​:22 PM, James E Keenan via RT wrote​:

On Mon, 09 Jan 2017 05​:47​:27 GMT, khw wrote​:

On Tue, 31 May 2016 09​:56​:37 -0700, public@​khwilliamson.com wrote​:

On 05/31/2016 07​:30 AM, Smylers wrote​:

Ricardo SIGNES writes​:

We have been working (slowwwly) for years to remove Pod​::Parser
from
the core perl distribution. At this point, I believe the only
blocker
is Pod​::Checker.

Karl Williamson has heroically achieved this (in RT #116467).

However, perlpodspec is still promoting Pod​::Parser in a couple of
places. Would readers be better served by being pointed at
Pod​::Simple
instead?

Good catch

This one can be addressed by simply changing the module name​:

Authors of Pod formatters/processors should make every effort to
avoid
writing their own Pod parser. There are already several in CPAN,
with
a wide range of interface styles -- and one of them, Pod​::Parser,
comes with modern versions of Perl.

Would you like to submit a patch for this? If so, I guarantee it
will
get applied.

But this one is trickier​:

In parsing Pod, a notably tricky part is the correct parsing of
(potentially nested!) formatting codes. Implementors should
consult
the code in the "parse_text" routine in Pod​::Parser as an example
of a
correct implementation.

What's the equivalent place in Pod​::Simple that would serve as an
example of how to get this right?

This one is tricky because the code in Pod​::Simple/BlackBox.pm that
mostly deals with this have various comments in it like​:

# Are you really sure you want to read this code?
# - - - Turn back now! Run away! - - -
## stop reading now stop reading now stop reading now stop reading
now stop
##
## HERE IT BECOMES REALLY SCARY
##
## stop reading now stop reading now stop reading now stop reading
now stop

So I don't know, I'd be ok with leaving the Pod​::Parser reference in
here (though I have never looked at its code actually)

Smylers

In lieu of a patch from Smylers, I pushed one myself for the first
reference to Pod​::Parser in perlpodspec as
67e5e059984f24c6c80a0f8278e40ce418d15c8b. I left the reference in
that said to refer to it if you're writing a replacement. This is
because of the comments in Pod​::Simple that are designed to scare
people away.

Pod​::Parser will not be removed in 5.26, as there is still a
dependency on it. So, I'm moving this ticket to block 5.28 instead.
The dependency is that it is the only way to extract just the pod from
a larger file. I made significant headway in reimplementing that in
Pod​::Simple, but shelved it to work on higher priority things for
5.26. I intend to finish it up once 5.26 is in code freeze.

Karl, do you have a battle plan for the removal of Pod-Parser from core now that 5.26.0 is out the door?

Are there parts that could be delegated to other people?

Thank you very much.

I did not get to this during the code freeze. It involves deep work in
Pod​::Simple, and I don't think anybody else is doing anything on that
module these days.

It is #3 on my todo list right now, and I should get to it in a few weeks.

From @khwilliamson

On Thu, 01 Jun 2017 20​:59​:47 -0700, public@​khwilliamson.com wrote​:

On 06/01/2017 07​:22 PM, James E Keenan via RT wrote​:

On Mon, 09 Jan 2017 05​:47​:27 GMT, khw wrote​:

On Tue, 31 May 2016 09​:56​:37 -0700, public@​khwilliamson.com wrote​:

On 05/31/2016 07​:30 AM, Smylers wrote​:

Ricardo SIGNES writes​:

We have been working (slowwwly) for years to remove Pod​::Parser
from
the core perl distribution. At this point, I believe the only
blocker
is Pod​::Checker.

Karl Williamson has heroically achieved this (in RT #116467).

However, perlpodspec is still promoting Pod​::Parser in a couple of
places. Would readers be better served by being pointed at
Pod​::Simple
instead?

Good catch

This one can be addressed by simply changing the module name​:

Authors of Pod formatters/processors should make every effort to
avoid
writing their own Pod parser. There are already several in CPAN,
with
a wide range of interface styles -- and one of them, Pod​::Parser,
comes with modern versions of Perl.

Would you like to submit a patch for this? If so, I guarantee it
will
get applied.

But this one is trickier​:

In parsing Pod, a notably tricky part is the correct parsing of
(potentially nested!) formatting codes. Implementors should
consult
the code in the "parse_text" routine in Pod​::Parser as an example
of a
correct implementation.

What's the equivalent place in Pod​::Simple that would serve as an
example of how to get this right?

This one is tricky because the code in Pod​::Simple/BlackBox.pm that
mostly deals with this have various comments in it like​:

# Are you really sure you want to read this code?
# - - - Turn back now! Run away! - - -
## stop reading now stop reading now stop reading now stop reading
now stop
##
## HERE IT BECOMES REALLY SCARY
##
## stop reading now stop reading now stop reading now stop reading
now stop

So I don't know, I'd be ok with leaving the Pod​::Parser reference
in
here (though I have never looked at its code actually)

Smylers

In lieu of a patch from Smylers, I pushed one myself for the first
reference to Pod​::Parser in perlpodspec as
67e5e059984f24c6c80a0f8278e40ce418d15c8b. I left the reference in
that said to refer to it if you're writing a replacement. This is
because of the comments in Pod​::Simple that are designed to scare
people away.

Pod​::Parser will not be removed in 5.26, as there is still a
dependency on it. So, I'm moving this ticket to block 5.28 instead.
The dependency is that it is the only way to extract just the pod
from
a larger file. I made significant headway in reimplementing that in
Pod​::Simple, but shelved it to work on higher priority things for
5.26. I intend to finish it up once 5.26 is in code freeze.

Karl, do you have a battle plan for the removal of Pod-Parser from
core now that 5.26.0 is out the door?

Are there parts that could be delegated to other people?

Thank you very much.

I did not get to this during the code freeze. It involves deep work
in
Pod​::Simple, and I don't think anybody else is doing anything on that
module these days.

It is #3 on my todo list right now, and I should get to it in a few
weeks.

I did not get to it until recently. I have a branch where podcheck.t no longer relies on Pod​::Parser.. However, it turns out there are other dependencies on this module, and I'm unsure what to do. Besides plain Pod​::Parser, the distribution includes
Pod​::ParseUtils
Pod;​:InputObjects
Pod​::Select

and there are 3 tests that check for these​:
'lib/Pod/t/InputObjects.t'
'lib/Pod/t/Select.t'
'lib/Pod/t/utils.t'

If I remove these tests, everything passes.

Shall I remove these?

--
Karl Williamson

From @cpansprout

On Sat, 19 May 2018 14​:41​:40 -0700, khw wrote​:

I did not get to it until recently. I have a branch where podcheck.t
no longer relies on Pod​::Parser.. However, it turns out there are
other dependencies on this module, and I'm unsure what to do. Besides
plain Pod​::Parser, the distribution includes
Pod​::ParseUtils
Pod;​:InputObjects
Pod​::Select

and there are 3 tests that check for these​:
'lib/Pod/t/InputObjects.t'
'lib/Pod/t/Select.t'
'lib/Pod/t/utils.t'

If I remove these tests, everything passes.

Shall I remove these?

Considering they begin with lib/Pod/, they probably belong in the Pod-Parser distribution (and predate the reorganization of the modules in 5.12 or so). Do they duplicate tests that Pod-Parser has? If so, they can go. If not, perhaps a patch to Pod-Parser could be submitted. (I admit I did not even look at them.)

I hope you are not intending to merge your branch until after 5.28 is released.

--

Father Chrysostomos

From @khwilliamson

This has finally been fixed by c57372c
--
Karl Williamson

@khwilliamson - Status changed from 'open' to 'pending release'

I'm just gonna point out, but this was removed without:

• a deprecation cycle (so there's no way CPAN would expose this missing in PREREQ_PM)
• a deprecation notice in Module::Metadata (so there's no way one could even ask if it was about to be removed from the tool who's job it is to advertise that )

# corelist CGI

Data for 2020-07-17
CGI was first released with perl 5.004, deprecated (will be CPAN-only) in v5.19.7 and removed from v5.21.0
# corelist Pod::Parser

Data for 2020-07-17
Pod::Parser was first released with perl v5.6.0 and removed from v5.31.1

The horse is bolted on that already, and we only noticed when we hit the first package that had this problem.

But there should be a system or reminder to prevent this happening in future.