Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove Pod::Parser from the core distribution #13194

Closed
p5pRT opened this issue Aug 23, 2013 · 24 comments
Closed

remove Pod::Parser from the core distribution #13194

p5pRT opened this issue Aug 23, 2013 · 24 comments
Labels
Milestone

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Aug 23, 2013

Migrated from rt.perl.org#119439 (status was 'pending release')

Searchable as RT119439$

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 23, 2013

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 3, 2013

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 3, 2013

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 3, 2013

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 3, 2013

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 3, 2013

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 3, 2013

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 19, 2014

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 19, 2014

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 24, 2014

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.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 25, 2014

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 25, 2014

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 5, 2014

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?

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 5, 2014

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 28, 2014

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented May 31, 2016

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented May 31, 2016

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 9, 2017

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 2, 2017

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)

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 2, 2017

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.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented May 19, 2018

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented May 20, 2018

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented May 30, 2019

From @khwilliamson

This has finally been fixed by c57372c
--
Karl Williamson

@p5pRT p5pRT closed this May 30, 2019
@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented May 30, 2019

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

@toddr toddr added this to the 5.32.0 milestone Oct 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.