Mailing List Archive

On Sun, 09 Apr 2023 11:01:41 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

> *tl;dr*: I would like to carry out the deprecations as committed,
> although I think the smartmatch one is more questionable. I would
> like to hear from more of the core team about this.

(with my PSC hat on)

The topic of deprecating both tick-as-separator and smartmatch came up
in the past few PSC meetings, we discussed it several times, and every
time we've concluded that we want to keep those deprecations in Perl
5.38.0.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

> From: Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
> The downside is some potential breakage to "some
> code". OK. Whose code? We've been asking around on this list for several weeks
> now for a list of what
> *actual* modules are *actually* broken by this and I
> don't think we've got such a list. Is there such a list?

This approach of narrowing the task is wrong.
Not everything resides in CPAN modules.
There are actual projects in the wild w/o CPAN or even github/lab/etc uploads.

I never used smartmatch myself but I do work with it in
code that is already written.

Decision on removal would mean stop perl upgrade on those setups
(right now those setups do Perl upgrade with regular Ubuntu upgrades)


> In summary:
> I am fully in favour of smartmatch and given/when, and tick-as-separator both
> being marked as deprecated in the 5.38.0 release.

This introduces another incompatibility step, which is pity to observe.

However this is not a first occasion of Perl breaking backward compat promises.

Because of such minor incompatibilities Strawberry perl just stopped binary builds on 5.32 version.
This 2+-year miss means forever.
And therefore significant loss of user base.
No new projects for a long time already, and no upgrades to smartmatch-lacking version at all.

You can continue ignoring such problems and continue improving perl by degrading its user base,
so stupid users will not stand on the way of your improving perl

If you do think about users - then follow the Python way: at the day of release there should be
battery-included windows build.

On Sun, 23 Apr 2023 at 15:42, Vadim V Konovalov via perl5-porters
<perl5-porters@perl.org> wrote:
>
> > From: Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
> > The downside is some potential breakage to "some
> > code". OK. Whose code? We've been asking around on this list for several weeks
> > now for a list of what
> > *actual* modules are *actually* broken by this and I
> > don't think we've got such a list. Is there such a list?
>
> This approach of narrowing the task is wrong.
> Not everything resides in CPAN modules.
> There are actual projects in the wild w/o CPAN or even github/lab/etc uploads.
>
> I never used smartmatch myself but I do work with it in
> code that is already written.
>
> Decision on removal would mean stop perl upgrade on those setups
> (right now those setups do Perl upgrade with regular Ubuntu upgrades)

All that code needs to do for the short term is disable the warnings
from these deprecations.

The issue we suffer from is that some people turn these warnings into
errors, either literally with warnings FATAL or indirectly by testing
that their code is warning free, and treating any warning as a fatal
exception. Normal code that does neither should at worst see new
warnings, which is unavoidable.

>
> > In summary:
> > I am fully in favour of smartmatch and given/when, and tick-as-separator both
> > being marked as deprecated in the 5.38.0 release.
>
> This introduces another incompatibility step, which is pity to observe.
>
> However this is not a first occasion of Perl breaking backward compat promises.
>
> Because of such minor incompatibilities Strawberry perl just stopped binary builds on 5.32 version.
> This 2+-year miss means forever.

Can you explain in more detail about this?

> And therefore significant loss of user base.
> No new projects for a long time already, and no upgrades to smartmatch-lacking version at all.
>
> You can continue ignoring such problems and continue improving perl by degrading its user base,
> so stupid users will not stand on the way of your improving perl
>
> If you do think about users - then follow the Python way: at the day of release there should be
> battery-included windows build.
>

I dont really follow you here. The whole point of a deprecation is
that it warns, providing or not a battery-included windows build is
orthagonal to whether people will be inconvenienced by these
deprecations.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

> From: demerphq

> > Because of such minor incompatibilities Strawberry perl just stopped binary builds on 5.32 version.
> > This 2+-year miss means forever.
>
> Can you explain in more detail about this?

You can see that strawberryperl.com has 5.32.1 binary.

This is my personal feeling that lack of fresh strawberry build is related to difficulties
of rebuilding battery-modules because of incompatibilities.

My personal feeling could be wrong or misleading but I don't have another guess on why it stopped releases.

> I dont really follow you here. The whole point of a deprecation is
> that it warns

Deprecation is about warns at first, planning for further removal in next version, isn't it?

> providing or not a battery-included windows build is
> orthagonal to whether people will be inconvenienced by these deprecations.

Ok, battery-included windows build will be even more difficult after new deprecations and core removals.
And it is critical for keeping users base (IMO)

On Sun, 23 Apr 2023 13:42:38 +0000
Vadim V Konovalov via perl5-porters <perl5-porters@perl.org> wrote:

> This introduces another incompatibility step, which is pity to observe.
>
> However this is not a first occasion of Perl breaking backward compat promises.
>
> Because of such minor incompatibilities Strawberry perl just stopped binary builds on 5.32 version.
> This 2+-year miss means forever.
> And therefore significant loss of user base.
> No new projects for a long time already, and no upgrades to smartmatch-lacking version at all.
>
> You can continue ignoring such problems and continue improving perl by degrading its user base,
> so stupid users will not stand on the way of your improving perl
>
> If you do think about users - then follow the Python way: at the day of release there should be
> battery-included windows build.

This is completely false. Strawberry Perl builds stopped because its
sole maintainer stepped down and no one was prepared to replace him.
Unfamiliar toolchain etc.

This is pretty much resolved now. The work on the 5.36 release is
progressing and there are test builds available:

https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/39#issuecomment-1518434188

> From: Tomasz Konojacki

> > If you do think about users - then follow the Python way: at the day
> > of release there should be battery-included windows build.
>
> This is completely false. Strawberry Perl builds stopped because its sole
> maintainer stepped down and no one was prepared to replace him.
> Unfamiliar toolchain etc.


I see logic error here.

The statement "follow Python practice to please users" (rephrased) isn't "completely false"

>
> This is pretty much resolved now. The work on the 5.36 release
> is progressing and there are test builds available:
>
> https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/39#issuecomment-1518434188

I would be more than happy to see it alive again

Thanks for letting me know

I still think the rule "release when windows battery-build is ready" would be a big step forward

I don't believe that the development of Perl as a language depends on how a
third-party packaging organization is able to maintain it. Nor do
deprecations have any significant impact on its ability to be maintained on
Windows. Deprecations are clearly *necessary*, and there's no way around
that. Any third-party organization packaging Perl has dealt with
deprecations before and will deal with deprecations satisfactorily in the
future.

On Mon, 24 Apr 2023 at 06:57, Vadim V Konovalov via perl5-porters <
perl5-porters@perl.org> wrote:

> > From: Tomasz Konojacki
>
> > > If you do think about users - then follow the Python way: at the day
> > > of release there should be battery-included windows build.
> >
> > This is completely false. Strawberry Perl builds stopped because its sole
> > maintainer stepped down and no one was prepared to replace him.
> > Unfamiliar toolchain etc.
>
>
> I see logic error here.
>
> The statement "follow Python practice to please users" (rephrased) isn't
> "completely false"
>
> >
> > This is pretty much resolved now. The work on the 5.36 release
> > is progressing and there are test builds available:
> >
> >
> https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/39#issuecomment-1518434188
>
> I would be more than happy to see it alive again
>
> Thanks for letting me know
>
> I still think the rule "release when windows battery-build is ready" would
> be a big step forward
>

Hi there,

On Fri, 21 Apr 2023, Paul "LeoNerd" Evans wrote:

> (with my personal hat on)

Ditto. FWIW.

> ... I am fully in favour of smartmatch and given/when, and
> tick-as-separator both being marked as deprecated in the 5.38.0 release.

+1

(1) I don't recall ever reading any code that used tick-as-separator,
and I've never used it myself. Nobody needs that kind of confusion.

(2) Everybody who's used smartmatch must always have known that it was
an experiment. They could hardly have failed to notice that it wasn't
a great success. If they're using it in code that's running now, what
happens to it on deprecation is to be expected.

(3) According to my notes, I experimented with given/when beginning
one day in 2017 which as it happens was my birthday; maybe I thought
it was going to be a treat, I don't remember. I do remember that the
experiment turned into a nightmare. I consigned it to the bin. I'd
have been happy to see it removed years ago.

As far as I'm concerned these are junk which can't be gone too soon -
and I feel there's no pressing need for replacements. Stop digging.

--

73,
Ged.

Denying the problem isn’t the best way to solve it

From: Avery Adams <oldtechaa@gmail.com>
Sent: Monday, April 24, 2023 12:43 AM
To: ????????? ????? ???????????? <vadim.konovalov@gazprombank.ru>
Cc: perl5-porters@perl.org
Subject: Re: Re: v5.37's deprecations

I don't believe that the development of Perl as a language depends on how a third-party packaging organization is able to maintain it. Nor do deprecations have any significant impact on its ability to be maintained on Windows. Deprecations are clearly necessary, and there's no way around that. Any third-party organization packaging Perl has dealt with deprecations before and will deal with deprecations satisfactorily in the future.

On Mon, 24 Apr 2023 at 06:57, Vadim V Konovalov via perl5-porters <perl5-porters@perl.org<mailto:perl5-porters@perl.org>> wrote:
> From: Tomasz Konojacki

> > If you do think about users - then follow the Python way: at the day
> > of release there should be battery-included windows build.
>
> This is completely false. Strawberry Perl builds stopped because its sole
> maintainer stepped down and no one was prepared to replace him.
> Unfamiliar toolchain etc.


I see logic error here.

The statement "follow Python practice to please users" (rephrased) isn't "completely false"

>
> This is pretty much resolved now. The work on the 5.36 release
> is progressing and there are test builds available:
>
> https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/39#issuecomment-1518434188

I would be more than happy to see it alive again

Thanks for letting me know

I still think the rule "release when windows battery-build is ready" would be a big step forward

Op 23-04-2023 om 20:57 schreef Vadim V Konovalov via perl5-porters:
>> From: Tomasz Konojacki
>>> If you do think about users - then follow the Python way: at the day
>>> of release there should be battery-included windows build.
>> This is completely false. Strawberry Perl builds stopped because its sole
>> maintainer stepped down and no one was prepared to replace him.
>> Unfamiliar toolchain etc.
>
> I see logic error here.
>
> The statement "follow Python practice to please users" (rephrased) isn't "completely false"


The "completely false" was a completely valid point to a much wider
context, which you snipped away.


HTH,

M4

> From: Martijn Lievaart
> Op 23-04-2023 om 20:57 schreef Vadim V Konovalov via perl5-porters:
> >> From: Tomasz Konojacki
> >>> If you do think about users - then follow the Python way: at the day
> >>> of release there should be battery-included windows build.
> >> This is completely false. Strawberry Perl builds stopped because its
> >> sole maintainer stepped down and no one was prepared to replace him.
> >> Unfamiliar toolchain etc.
> >
> > I see logic error here.
> >
> > The statement "follow Python practice to please users" (rephrased) isn't "completely false"
>
> The "completely false" was a completely valid point to a much wider context,
> which you snipped away.

Yes, you continue to ignore the problem.
Call all the problems "completely false" and ignore stupid users who stand on the way.

Some ~10 years ago suggestion to rename perl5 to perl7 was also considered completely wrong
and ignoring perl6 reputation damage was the main trend.
After that "perl7" idea was accepted but it was too late.

Yes, call me stupid and completely wrong and everyone be happy (including me:))

Op 25-04-2023 om 06:34 schreef Vadim V Konovalov via perl5-porters:
>> From: Martijn Lievaart
>> Op 23-04-2023 om 20:57 schreef Vadim V Konovalov via perl5-porters:
>>>> From: Tomasz Konojacki
>>>>> If you do think about users - then follow the Python way: at the day
>>>>> of release there should be battery-included windows build.
>>>> This is completely false. Strawberry Perl builds stopped because its
>>>> sole maintainer stepped down and no one was prepared to replace him.
>>>> Unfamiliar toolchain etc.
>>> I see logic error here.
>>>
>>> The statement "follow Python practice to please users" (rephrased) isn't "completely false"
>> The "completely false" was a completely valid point to a much wider context,
>> which you snipped away.
> Yes, you continue to ignore the problem.
> Call all the problems "completely false" and ignore stupid users who stand on the way.


I do not ignore the problem, I point out that you ignore what Tomasz
wrote, and just continue banging on about everybody but you being wrong.
That's not a discussion, that's a monologue. Which you continue here again.


You are entitled to your opinion, but please do interact. Read what
others write and try to get into their arguments. As others do with your
opinions, even if you don't think they do (but that seems exactly to be
the problem).


>
> Some ~10 years ago suggestion to rename perl5 to perl7 was also considered completely wrong
> and ignoring perl6 reputation damage was the main trend.
> After that "perl7" idea was accepted but it was too late.
>
> Yes, call me stupid and completely wrong and everyone be happy (including me:))
>

I do not call you stupid. Stop suggesting that anyone calls you stupid.
It doesn't help your point.


Regards,

M4

> From: Martijn Lievaart
> Op 25-04-2023 om 06:34 schreef Vadim V Konovalov via perl5-porters:
> >> From: Martijn Lievaart
> >> Op 23-04-2023 om 20:57 schreef Vadim V Konovalov via perl5-porters:
> >>>> From: Tomasz Konojacki
> >>>>> If you do think about users - then follow the Python way: at the
> >>>>> day of release there should be battery-included windows build.
> >>>> This is completely false. Strawberry Perl builds stopped because
> >>>> its sole maintainer stepped down and no one was prepared to replace him.
> >>>> Unfamiliar toolchain etc.
> >>> I see logic error here.
> >>>
> >>> The statement "follow Python practice to please users" (rephrased) isn't "completely false"
> >> The "completely false" was a completely valid point to a much wider
> >> context, which you snipped away.
> > Yes, you continue to ignore the problem.
> > Call all the problems "completely false" and ignore stupid users who stand on the way.
>
>
> I do not ignore the problem, I point out that you ignore what Tomasz wrote,
> and just continue banging on about everybody but you being wrong.

Not so.
I am not stating that everyone is wrong

> That's not a
> discussion, that's a monologue. Which you continue here again.

Ok, initially I wrote an argumentation why I disagree with Tomasz but finally decided to trash it to
not waste people's time into lengthy explanation why exactly "completely false"
was wrong. In short - that B&W statement doesn’t apply here.

> You are
> entitled to your opinion, but please do interact. Read what
> others write and try to get into their arguments. As others do with your
> opinions, even if you
> don't think they do (but that seems exactly to be the problem).

So because of me trashing lengthy explanation, it appeared like I was not reading/understanding
other's people messages carefully. Sorry for that.

Ok point taken, I was heard, probably understood and all that.
Thanks :)

On Tue, Apr 25, 2023 at 07:48:37AM +0000, Perl 5 Porters wrote:
>
> Ok point taken, I was heard, probably understood and all that.

Happy to see that what seemed to inexorably escalate into a flame war
just got resolved. Sincere thanks to everyone involved!

--
Philippe Bruhat (BooK)

No magic gnome may come to you / and offer you the question-
But should you ever get a wish / we have a good suggestion.
The greatest gift to wish for / if your magic wish comes true-
A friend who's as devoted / as Rufferto is to Groo.
(Moral from Groo The Wanderer #77 (Epic))

Follow-up, in the context of a conversation happening at PTS 2023 Lyon:

This issue is specifically warned about at
https://metacpan.org/pod/Test::Warnings#CAVEATS. Any complaints about
misbehaving modules directed to authors can be pointed to this.


On Tue, Apr 11, 2023 at 6:05?AM Karen Etheridge <perl@froods.org> wrote:

> On Mon, Apr 10, 2023 at 4:17?AM demerphq <demerphq@gmail.com> wrote:
>
>> I don't think it is strange at all that people check their code is
>> warning free. That they do it as part of normal regression tests is
>> irritating but also understandable given we really don't document author
>> testing as being a distinct
>>
>
> FWIW, I have been doing this in all my cpan tests for many years now:
>
> ...
> use if $ENV{AUTHOR_TESTING}, 'Test::Warnings';
>
> ...which means that warnings will be treated as failures when testing
> locally (either by setting the environment variable manually, or when set
> via `dzil test`), but not when shipped, which allows warnings from upstream
> modules to still exist while not preventing installation.
>