Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
Thread Previous
|
Thread Next
From:
David E. Wheeler
Date:
June 30, 2009 13:00
Subject:
Re: Perl 5.10.1
Message ID:
D3FF701B-E8C2-4149-BF99-2A0E3D77DB73@kineticode.com
On Jun 30, 2009, at 12:44 PM, Nicholas Clark wrote:
> 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.
It has been appreciated, though. It was crazy, and perhaps enabled
everyone else to be lazy (in the negative sense), but much appreciated.
>> 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
Right.
> 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/
Link/discussion?
> 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
Oh, this is do-able by pretty much anyone who puts code on CPAN.
Perhaps a bunch of us could do this at a hackathon at OSCON? I'm
assuming 1.10.1 will be out by then.
> 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)
Oh, very nice.
> 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.
Why not introduce such deprecations in 1.10.2 and make them go away in
5.12? Too much work?
> 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)
Could such a list go into an installed file that CPAN(?:PLUS)? could
just read?
> 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.
This is also do-able, I think (both have accepted patches pretty
willingly, IME).
> 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
Yeah, I do this already. /me hates failing tests from his CPAN modules.
> 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.
Okay. I've been thinking that I need to script testing all of my
modules on various versions of Perl anyway, to test new versions of
Module::Build, Test::More, etc. So maybe I'll go ahead and do that.
> 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.
Do we have cpan testers who regularly build from blead and test CPAN
modules with it? That way they can notify said authors of any issues.
That would be a way to get more CPAN authors involved more quickly. I
seem to recall that someone did this for 1.10RC1, but it'd be nice to
do it in blead all the time. Continuous testing, that is.
>> 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)
Ow my head hurts. I need an nclark wiki with separate pages for each
of these ideas, with a TOC listing in what order things ought to be
done…
But first, helping with 5.10.1 issues Thursday evening.
Best,
David
Thread Previous
|
Thread Next