Mailing List Archive

On Thu, Mar 21, 2024 at 02:55:07PM -0700, Chad Granum wrote:
> So for these reasons I am seeking input from the group on if reunification
> of the sundered dist back into a single dist is acceptable now that they
> are both in core?

How will the reunification affect Perl 5.38 and older?


Thank you.

--
+-------------------------------------------+
| Marcel Telka e-mail: marcel@telka.sk |
| homepage: http://telka.sk/ |
+-------------------------------------------+

On Thu, Mar 21, 2024 at 5:55?PM Chad Granum <exodist7@gmail.com> wrote:

> In the perl 5.39.x branch Test2::Suite has been put into perl core.
>
> Originally Test2-Suite and all its contents were written to be part of the
> same Dist as Test2::API, and other things which are in Test-Simple. I split
> the functionality out at the urging of RJBS to make it easier to get Test2
> accepted into core as the Test2-Suite stuff was less obvious a match.
>
> Now that both dists are in core I would like to merge them back into one
> dist, and Test-Simple as the dist name makes the most sense for
> legacy/sanity reasons.
>
> My justification is that it will make maintenance significantly easier. It
> will also put the Test2::API documentation into the dist where Test2::API
> actually lives. (Currently the Test2 manual lives in Test2-Suite, but 90%
> of what it documents is in Test-Simple). I also constantly get bug reports
> and feature requests on the wrong dist as it is often quite hard to
> determine which dist the issue belongs to.
>
> Maintenance is hard right now because Test2::Suite is written using
> private internals of Test2::API, so whenever those internals change
> Test2-Suite will break without absurd contorting for compatibility with
> older internal APIs. Right at this moment I have a change I want to make
> that will boost performance slightly. But I cannot do it because making the
> internal API change in Test-Simple breaks Test2-Suite and the only way to
> fix it is a new Test2::Suite release, but that would mean installing
> Test-Simple without upgrading Test2-Suite would break the already installed
> Test2-Suite, which I find unacceptable (so am not releasing this change at
> this time).
>
> So for these reasons I am seeking input from the group on if reunification
> of the sundered dist back into a single dist is acceptable now that they
> are both in core?
>

Seems reasonable to me. See the Math-BigInt/Math-BigRat recent merge for
similar precedent. Might be simpler to do after the 5.40 release?

-Dan

On 3/21/24 19:00, Dan Book wrote:
> On Thu, Mar 21, 2024 at 5:55?PM Chad Granum <exodist7@gmail.com
> <mailto:exodist7@gmail.com>> wrote:
>
> [snip]
>
>
> Seems reasonable to me. See the Math-BigInt/Math-BigRat recent merge for
> similar precedent. Might be simpler to do after the 5.40 release?
>

Definitely not until the next dev cycle. After that, this will bear
serious consideration, and if we decide to go ahead we should do it
early in that cycle.

On Thu, Mar 21, 2024 at 7:00?PM Dan Book <grinnz@gmail.com> wrote:

> On Thu, Mar 21, 2024 at 5:55?PM Chad Granum <exodist7@gmail.com> wrote:
>
>> In the perl 5.39.x branch Test2::Suite has been put into perl core.
>>
>> Originally Test2-Suite and all its contents were written to be part of
>> the same Dist as Test2::API, and other things which are in Test-Simple. I
>> split the functionality out at the urging of RJBS to make it easier to get
>> Test2 accepted into core as the Test2-Suite stuff was less obvious a match.
>>
>> Now that both dists are in core I would like to merge them back into one
>> dist, and Test-Simple as the dist name makes the most sense for
>> legacy/sanity reasons.
>>
>> My justification is that it will make maintenance significantly easier.
>> It will also put the Test2::API documentation into the dist where
>> Test2::API actually lives. (Currently the Test2 manual lives in
>> Test2-Suite, but 90% of what it documents is in Test-Simple). I also
>> constantly get bug reports and feature requests on the wrong dist as it is
>> often quite hard to determine which dist the issue belongs to.
>>
>> Maintenance is hard right now because Test2::Suite is written using
>> private internals of Test2::API, so whenever those internals change
>> Test2-Suite will break without absurd contorting for compatibility with
>> older internal APIs. Right at this moment I have a change I want to make
>> that will boost performance slightly. But I cannot do it because making the
>> internal API change in Test-Simple breaks Test2-Suite and the only way to
>> fix it is a new Test2::Suite release, but that would mean installing
>> Test-Simple without upgrading Test2-Suite would break the already installed
>> Test2-Suite, which I find unacceptable (so am not releasing this change at
>> this time).
>>
>> So for these reasons I am seeking input from the group on if
>> reunification of the sundered dist back into a single dist is acceptable
>> now that they are both in core?
>>
>
> Seems reasonable to me. See the Math-BigInt/Math-BigRat recent merge for
> similar precedent. Might be simpler to do after the 5.40 release?
>

The only complication I foresee this introducing is adding additional
dependencies for distributions requiring a newer Test::More when installed
on older perls. But the dependency list is trivial at this point.

-Dan

On Thu, 21 Mar 2024 at 22:55, Chad Granum <exodist7@gmail.com> wrote:

> In the perl 5.39.x branch Test2::Suite has been put into perl core.
>
> Originally Test2-Suite and all its contents were written to be part of the
> same Dist as Test2::API, and other things which are in Test-Simple. I split
> the functionality out at the urging of RJBS to make it easier to get Test2
> accepted into core as the Test2-Suite stuff was less obvious a match.
>
>
Just for curiosity, did you fix Test2 to produce valid TAP by default ?

If not, I think this merge should not be done, risking additional costs on
users (especially private codebases).

Best regards,
Brano

On Fri, Mar 22, 2024 at 6:26?AM Branislav Zahradník <happy.barney@gmail.com>
wrote:

>
> Just for curiosity, did you fix Test2 to produce valid TAP by default ?
>
> If not, I think this merge should not be done, risking additional costs on
> users (especially private codebases).
>

Branislav, can you provide a small test case which demonstrates the issue?
Without that, it's hard to contextualize.

Plus, having Test2 in core doesn't mean people are forced to switch to it.

Best,
Ovid

On Fri, Mar 22, 2024 at 1:26?AM Branislav Zahradník <happy.barney@gmail.com>
wrote:

>
>
> On Thu, 21 Mar 2024 at 22:55, Chad Granum <exodist7@gmail.com> wrote:
>
>> In the perl 5.39.x branch Test2::Suite has been put into perl core.
>>
>> Originally Test2-Suite and all its contents were written to be part of
>> the same Dist as Test2::API, and other things which are in Test-Simple. I
>> split the functionality out at the urging of RJBS to make it easier to get
>> Test2 accepted into core as the Test2-Suite stuff was less obvious a match.
>>
>>
> Just for curiosity, did you fix Test2 to produce valid TAP by default ?
>
> If not, I think this merge should not be done, risking additional costs on
> users (especially private codebases).
>

Nothing proposed here changes the behavior of any program, in fact it
changes nothing except the size and dependencies of an updated Test-Simple
distribution.

-Dan

On Fri, 22 Mar 2024 at 09:20, Ovid <curtis.poe@gmail.com> wrote:

> On Fri, Mar 22, 2024 at 6:26?AM Branislav Zahradník <
> happy.barney@gmail.com> wrote:
>
>>
>> Just for curiosity, did you fix Test2 to produce valid TAP by default ?
>>
>> If not, I think this merge should not be done, risking additional costs
>> on users (especially private codebases).
>>
>
> Branislav, can you provide a small test case which demonstrates the
> issue? Without that, it's hard to contextualize.
>
>
https://github.com/Test-More/Test2-Suite/issues/250

also your related comment:
https://github.com/TestAnything/Specification/issues/34#issuecomment-1247650815



> Plus, having Test2 in core doesn't mean people are forced to switch to it.
>

If so, than it should remain package on it's own.
Test2 is different beast, should not have anything related with anything
from "Test1"


>
> Best,
> Ovid
>

On Fri, Mar 22, 2024, at 07:34, Branislav Zahradník wrote:
>> Plus, having Test2 in core doesn't mean people are forced to switch to it.
>
> If so, than it should remain package on it's own.

That doesn't make sense to me.

Ovid wrote, "Having Test2 won't force people to use it."

You wrote, "Then it should remain on its own."

This sounds like, "We should only package with core those libraries that people must switch to using", which is obviously not how things work.

> Test2 is different beast, should not have anything related with anything from "Test1"

This is also strange and I don't quite follow.

It seems to me like the situation is as follows:

Ages ago, we added the kernel of Test2 to core because we wanted to let the old Test::Builder be well and truly left behind, and to have a smoother way for people to move to Test2::API, which is superior in many ways to Test2::Builder. I said, "This is going to be easier if we focus on that goal, rather than all the extra test tools currently bundled together with Test2::API."

Chad went along with this, because it looked like the way to get things done, and indeed we did get Test2::API shipped with core.

Years later, Test2-Suite — the stuff that Chad split apart years ago — is now also being added in core. Here's some of the reasoning that was given six months ago when it happened:
> This distribution [Test2-Suite] contains a comprehensive set of test tools for writing unit tests. It is the successor to Test::More and similar modules. Its inclusion in the Perl core means that CPAN module tests can be written using this suite of tools without extra dependencies.

I take this as "we want to use things in Test2-Suite to test things in core, so we need to do this".

Chad says, "Look, this was only split into two pieces for a now-obsolete reason. Now it's just a hassle. I want to eliminate the hassle."

Your (Branislav's) objection seems to be that you really don't like that Test2::Suite includes tools that emit something other than "standard" TAP. Most specifically:
*# THIS IS STANDARD TAP*
snowdrop:~$ perl -MTest::More -e 'subtest x => sub { pass }; done_testing'
# Subtest: x
ok 1
1..1
ok 1 - x
1..1

*# THIS IS Test2::V0's "BRACED SUBTEST" FORM*
snowdrop:~$ perl -MTest2::V0 -e 'subtest x => sub { pass }; done_testing'
# Seeded srand with seed '20240322' from local date.
ok 1 - x {
ok 1
1..1
}
1..1

This brings us back to Ovid's line way above: nobody is being forced to switch from the old style to braced style. They'll have to go change their code. If they do, it's because they want some benefit of this software. The software is already bundled with perl in blead. The only question is: *Should Chad have to slog through maintaining two distributions?*

???? I think the only reasonable answer is "no, of course not, let them be merged."

Finally, beyond the value in saving Chad's time: I think we are all better served by the architecture of Test2, where the test process is a sequence of events, with various ways of formatting them. Not every useful test process can be easily modeled as a TAP stream. It is better to let them move beyond TAP when it makes life easier for the person who's engaged in testing. TAP is very limiting, and the idea of "a TAP standard" has basically gone nowhere in the last *fifteen* years.

--
rjbs

On Sat, 23 Mar 2024 at 07:19, Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> On Fri, Mar 22, 2024, at 07:34, Branislav Zahradník wrote:
>
> Plus, having Test2 in core doesn't mean people are forced to switch to it.
>
>
> If so, than it should remain package on it's own.
>
> …
>

???? I think the only reasonable answer is "no, of course not, let them be
> merged."
>
> Finally, beyond the value in saving Chad's time: I think we are all better
> served by the architecture of Test2, where the test process is a sequence
> of events, with various ways of formatting them. Not every useful test
> process can be easily modeled as a TAP stream. It is better to let them
> move beyond TAP when it makes life easier for the person who's engaged in
> testing. TAP is very limiting, and the idea of "a TAP standard" has
> basically gone nowhere in the last *fifteen* years.
>
>
> --
> rjbs
>

+1 merge. Please…

>

On Thu, Mar 21, 2024 at 3:57?PM Marcel Telka <marcel@telka.sk> wrote:

> On Thu, Mar 21, 2024 at 02:55:07PM -0700, Chad Granum wrote:
> > So for these reasons I am seeking input from the group on if
> reunification
> > of the sundered dist back into a single dist is acceptable now that they
> > are both in core?
>
> How will the reunification affect Perl 5.38 and older?
>

(Assuming the change is not made until after 5.40 lands) I assume there
will be no effect at all, since already-released stable versions are
immutable, and we do not routinely update bundled cpan modules in point
releases (i.e. 5.40.1 will contain the same versions of Test::* as 5.40.0,
unless there is a critical bug that needs to be fixed for 5.40.1).

Based on this discussion thread, I will merge the 2 dists, but I will not
do so until after the 5.40 release in May. This does mean I cannot do the
merge at the PTS in 2 weeks, but I can live with that and wait for the
right time.

Thank you everyone!

-Chad

On Fri, Mar 22, 2024 at 8:51?PM Karen Etheridge <perl@froods.org> wrote:

> On Thu, Mar 21, 2024 at 3:57?PM Marcel Telka <marcel@telka.sk> wrote:
>
>> On Thu, Mar 21, 2024 at 02:55:07PM -0700, Chad Granum wrote:
>> > So for these reasons I am seeking input from the group on if
>> reunification
>> > of the sundered dist back into a single dist is acceptable now that they
>> > are both in core?
>>
>> How will the reunification affect Perl 5.38 and older?
>>
>
> (Assuming the change is not made until after 5.40 lands) I assume there
> will be no effect at all, since already-released stable versions are
> immutable, and we do not routinely update bundled cpan modules in point
> releases (i.e. 5.40.1 will contain the same versions of Test::* as 5.40.0,
> unless there is a critical bug that needs to be fixed for 5.40.1).
>
>
>