Re: Perl 5.10.1

Front page | perl.perl5.porters | Postings from June 2009

Thread Previous | Thread Next

From:

Nicholas Clark

Date:

June 30, 2009 12:45

Subject:

Re: Perl 5.10.1

Message ID:

20090630194459.GM33745@plum.flirble.org

On Tue, Jun 30, 2009 at 09:08:52AM -0700, David E. Wheeler wrote:

> (Nicholas Clark)++ # You're a one man releasing machine!

No I'm not. I need more than a little help from my friends.
I really don't work well as a one man anything. I go cranky rather rapidly.

Apparently, I'm not lazy enough, so I'll try to rectify that by copying
from perl589delta.pod wholesale:

=head1 Acknowledgements

Some of the work in this release was funded by a TPF grant.

Steve Hay worked behind the scenes working out the causes of the differences
between core modules, their CPAN releases, and previous core releases, and
the best way to rectify them. He doesn't want to do it again. I know this
feeling, and I'm very glad he did it this time, instead of me.

Paul Fenwick assembled a team of 18 volunteers, who broke the back of writing
this document. In particular, Bradley Dean, Eddy Tan, and Vincent Pit
provided half the team's contribution.

Schwern verified the list of updated module versions, correcting quite a few
errors that I (and everyone else) had missed, both wrongly stated module
versions, and changed modules that had not been listed.

The crack Berlin-based QA team of Andreas KE<ouml>nig and Slaven Rezic
tirelessly re-built snapshots, tested most everything CPAN against
them, and then identified the changes responsible for any module regressions,
ensuring that several show-stopper bugs were stomped before the first release
candidate was cut.

The other core committers contributed most of the changes, and applied most
of the patches sent in by the hundreds of contributors listed in F<AUTHORS>.

And obviously, Larry Wall, without whom we wouldn't have Perl.

=cut

> >However, I'm not arguing against reducing the number of (other)  
> >modules in
> >core. More than that - I've actually figured out what we need to do  
> >to do
> >this, bloody well gone and done that, and am now (I believe, by  
> >request)
> >waiting on 5.10.1 to ship (and juggling other things on my private  
> >TODO
> >list) before going beyond the test case for this (Switch.pm).
> 
> How can I help you with this?

I like questions like that.

Specifically, I think that the plan is roughly

0: Don't do any of this until 5.10.1 ships, because Dave asked us not to
1: Merge schwern's existing branch that changes tests in ext to run with
   the current directory set to ext/Foo-Bar rather than t/
2: Migrate dual life modules from lib to ext, in the process
   a: Rearranging the files structure in blead to be identical to their CPAN
      tarball
   b: Making the tests pass from ext/whatever (because right now they're all
      running with the chdir as t/)
3: See what's left in lib

but, probably, in parallel:

Right now, if you install blead you get this:

$ ~/Sandpit/snap5.9.x-GitLive-blead-1177-g2243c3b/bin/perl5.11.0 -MSwitch -we0
Switch will be removed from the Perl core distribution in the next major release. Please install it from CPAN. It is being used at -e, line 0.

If you happen to copy Switch.pm into sitelib, that goes away.
(See lib/deprecate.pm for how it's done)

That's the design, because blead's @INC order puts sitelib ahead of
archlib/privlib (where the core's modules live), and from 5.12 onwards
dual life modules need to change to always installing to sitelib, just like
any other module. (Which solves other problems)

What this means is that the action of explicitly installing the *same* module
from CPAN will cause the warning to go away, which is good, because in 5.14
people are going to have to do that.

But, right now, if I ask the CPAN shell to do this, it politely declines:

cpan[1]> install Switch
CPAN: Storable loaded ok (v2.20)
Going to read '/Users/nick/.cpan/Metadata'
  Database was generated on Tue, 30 Jun 2009 07:30:40 GMT
Switch is up to date (2.14_01).

cpan[2]> 

CPANPLUS probably likewise.

What needs to happen is to work out some way of

a: CPAN and CPANPLUS knowing which core modules are deprecated.
   (The list is currently just Switch, but will get longer before 5.12)

b: If a request to install one of those modules is issued, look to see where
   it was loaded from. If it's loaded from archlib/privlib, the location that
   warns, behave the same as if it's not installed, or out of date.

c: If not, behave as now. (No install without force)

"a" and "b" might be possible simply by having deprecate.pm record all modules
that called it that would trigger the warning, and have CPAN/CPANPLUS
interrogate that.

and then create patches that respectively Andreas and Jos are happy with.

Meanwhile, to help step "0" above - get 5.10.1 out, I think that the most
useful thing that you, as an author of quite a bit of code on CPAN, and
probably quite a bit of client code not on CPAN, could do is:

0: If you don't have one already, build a clean 5.10.0
1: Build your code against clean 5.10.0
2: Validate that it passes its regression tests, and works just fine

3: Build maint-5.10 from git, with the same configuration as 5.10.0
   (but a different install prefix, I think, to be safe)
4: Verify that it passes its own regression tests - it should.
5: Build your code against it
6: Validate that your code passes its regression tests, and works just fine.

Because if step 6 fails, that's some sort of behaviour change in maint-5.10,
and it would be nicer to know about those before an RC1 ships, rather than
aftwards, as that will leave Dave wondering whether he then needs to ship
an RC2 to validate that the solution is better than the problem.

> >>I hear it's a great little language for that sort of thing. ;-)
> >
> >There's this minor bootstrapping problem though - you can't be sure  
> >you
> >have a copy of it around whilst you're building it the first time.
> 
> Isn't a miniperl first compiled for that?

Yes, but the bootstrapping problem *seemed* to be that we needed the
information to build miniperl. (The solution was to change things so that
we did not. There is likely a bit more stuff in the core that is currently
done with shell scripts on Unix *after* miniperl is built, that could be
migrated to Perl, by stealing the code that Win32 or VMS uses, and unifying
it. Oops, another random TODO)

Nicholas Clark

Thread Previous | Thread Next