Skip to content

SC Notes 2020 08 18

Jump to bottom
Todd Rinaldo edited this page Aug 19, 2020 · 1 revision

Arrangements

  • Time: 2020-08-18 13:00 GMT
  • Location: Zoom
  • Invitees: Perl Steering Committee members

Attendees

Meeting notes

We did not come to today's meeting with any specific agenda but attendees determined that we would meet regardless. Todd and James agreed to provide a summary of their findings so far.

CPAN report from Todd.

So this last week we finally got a stable branch that would default Perl 7 to run with strict in all cases other than -e and -E. We wanted this because we wanted to see how broken the cPanel CPAN 1500 were. This is the set of RPMs cPanel regularly builds against new perls and ships to customers. Earlier in the week, we had setup an RPM that only had the version bump and confirmed a very small amount of fixable breakage. This is similar to the work that Jim is doing but my focus was to skip the problem with core Perl by injecting use v5; all over the Perl code base so I could instead inspect how bad CPAN was.

What I found was not great.

strict refs: There's evidence that Module::Install is manifesting yet another problem which makes it hard to move things forward without breaking every module that uses it. In this case, it's doing some ref shenanigans without first doing no strict 'refs'. We have found yet another example of why we can't have nice things because of M::I. sigh

strict subs: This should have been an easy one. EXCEPT that the major violator is Build.PL and Makefile.PL. You see it turns out that List::Util => 1 is a strict subs violation. Fat comma only quotes [a-zA-Z0-9] but more importantly explicitly DOES NOT work with ":". Which means anyone who didn't have strict on in Makefile.PL didn't realize they realize they had a broken fat comma.

strict vars: So it turns out that Tux's speculation that most people write with strict and warnings was correct... In their lib/ code. However it appears that many people do not have strict/warnings on in their tests. I'll share a personal module (IPC::Run) I've been trying to help limp along for years.

IPC::Run is mostly strict/warnings compliant except for its tests which didn't have it on at all. Even so, most of the tests were fine except for a few missed strictures that have crept in over the years. Just the same, a release would be required to get it to be ok with strict on by default.

In the end, I gave up without finishing the full analysis. 180 were already failing for various reasons. 800 modules hadn't even tried to build at that point because of missing dependencies. We tested about 180 out of 700. In other words, 1 in 4 were failing due to adding strict as a default.

There was also a mess with Module::Build which turned out to be a lack of strictness buried in Module::Metadata. It turned out to be an easy fix but we only just figured that out recently.

When we first started thinking about bumping the defaults for Perl 7, we very much from the start felt that any solution we provided was a non-starter if it left CPAN behind. Over the past year, we have discussed various approaches to make sure this doesn't happen. Some were more ambitious than others. I think the following is what I want to consider at this point.

  1. Provide a repo with patches in the form of https://github.com/perl/cpan7overlay/M/My-Distro-Name-1.2222-0001.patch files.
    • Make it possible for people to provide their own patches in this repo.
    • Patches are only permitted which make it easier to build/test/install.
    • cpan clients would probably apply these patches after extracting the tarball.
  2. Create module::compatibility that will walk a CPAN tarball (and maybe a private code base) and inject use v5 based on some automated logic. This has already proven to solve 99% of the problems in blead.
  3. Use module::compatibility to generate patches against as much of CPAN as possible. Submit PRs to cpan7overlay for human review.
    • Auto-open cases against the upstream CPAN module and point to the cpan7overlay PR so they're aware of what was done to work around it.

Before we spend time exploring this, we would ideally like to know: If CPAN was not broken with a Perl 7, would the other objections people have go from a 'non-starter' to a 'annoyance'? We don't know how to meaningfully ask let alone answer this question.

What are people concerned about?

Over the past few days, Nico and Todd also worked on an audit of everyone's concerns. There were many concerns, but believe it can be boiled down to a hand full of overall issues:

  1. Don't break CPAN
  2. Don't break tutorials/books
  3. I want my Perl 5 (don't fork the language/community)
  4. Don't start breaking backward compatibility.
    • People worry folks will move to another language if we do.
  5. Don't make distros do /usr/bin/perl7 AND /usr/bin/perl5
  6. The feature/dev process we have now is fine.
    • I prefer use vX.X not new defaults. (This is already how it works.)
    • We know of no new features that need a new process.
  7. There's not enough change to justify Perl 7.

Making blead strict compliant (Jim Keenan)

Jim gave a summary of the ongoing work he has been doing. Because of the concerns about the activity and noise in https://github.com/perl/perl5, Jim has been working in an alternate perl repo. The goal has been to change Perl to have strict defaults and then fix blead to be compliant with those changes.

Jim has presented his talk: "Perl 7, an Opinionated Introduction" at toronto.pm and houston.pm meetings in the past month. His ask to members, come help us fix blead by:

  1. Understand the goal of a small set of core tests.
  2. Review the breakage when strict is enabled in those tests
  3. Become the SME on these tests and provide fixes.

Several people have stepped forward from the Perl Monger meetings offering to help.

At this point, blead is strict compliant with the exception of 44 tests but they are probably the hardest ones to fix. because it is not clear what fixes would be needed to not change the nature of the tests.

Sawyer indicated that he was glad of this work. We would like to start adding these fixes to blead so more people could have visibility of the fixes. None of this work is something that couldn't have been done years ago.

Paul and Karl were going to see if they could help.

Configure

Tux asked about some of the changes pending and already in blead which would require changes to metaconfig. We agreed that putting some of those bits in a branch in metaconfig would be good.

And finally...

Sawyer spoke on where we would be going next. It was explicitly not in scope for the technical meeting, but sorting out governance is a key issue that needs to be addressed before we move forward.

We will likely do a 5.33.x release (soon) in the mean time.

Action items

  1. Jim is going to continue working on a strict blead.
  2. Todd and Nico are going to look at the CPAN overlay idea for Perl 7.
  3. Paul and Karl will be looking at Jim's work to see if they can help.
  4. Tux is going to work on metaconfig.

https://metacpan.org/release/perl

Clone this wiki locally