Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
I'll see to it that the pony goes into blead asap. Adam K 2008/10/4 Nicholas Clark <[EMAIL PROTECTED]>: > On Sat, Oct 04, 2008 at 01:55:50PM +1000, Adam Kennedy wrote: > >> The magic ponies will be introduced in 5.8.9 and 5.10.1. You indeed >> will never have to upgrade. > > 5.8.9 will ship, ponies ready or not. > > I don't see stable ponies in blead to merge. > > I'm not the only person who can commit to blead, so someone else can deal with > that part. > > Nicholas Clark >
Re: Module::Build 0.30 is released
On Wed, Oct 1, 2008 at 1:13 PM, Craig A. Berry <[EMAIL PROTECTED]> wrote: > On Tue, Sep 30, 2008 at 6:33 AM, Steve Hay <[EMAIL PROTECTED]> wrote: > >> Thanks, applied to bleadperl as 34446. >> >> Two local changes remain: >> >> Change 32357 by [EMAIL PROTECTED] on 2007/11/17 04:19:47 >> >>Skip Module::Build ppm test -- not ready for prime time on VMS. >> >> (ppm.t) This is a great deal closer to working than it was, but still not quite there yet. >> Change 32351 by [EMAIL PROTECTED] on 2007/11/16 23:43:46 >> >>Silence ill-behaved or failing Module::Build tests on VMS. >> >> (test_type.t and xs.t parts only--the tilde.t part appears to have been >> superseded by code in 0.30. Please can you check that, Craig?) This was ok for now but we have more work to do upstream. I see these new failures after the integration of 0.30: lib/Module/Build/t/compat.FAILED at test 13 lib/Module/Build/t/extFAILED at test 142 lib/Module/Build/t/tilde..FAILED at test 3 I think all of those were working last time I tried a CPAN version a few months ago but I obviously have not kept up on my testing. test_type.t and xs.t work fine individually but trigger a VMS-specific bug that causes the harness to see tests out of order. I think some output from a child process is bleeding through to the parent or something: $ perl test [-.lib.module.build.t]test_type.t lib/module/build/t/test_typeFAILED--expected test 5, saw test 4 Failed 1 test out of 1, 0.00% okay. [-.lib.module.build.t]test_type.t ### Since not all tests were successful, you may want to run some of ### them individually and examine any diagnostic messages they produce. ### See the INSTALL document's section on "make test". u=6.56 s=0.00 cu=0.00 cs=0.00 scripts=1 tests=9 %SYSTEM-F-ABORT, abort $ perl test [-.lib.module.build.t]xs.t lib/module/build/t/xsFAILED--expected test 12, saw test 11 Failed 1 test out of 1, 0.00% okay. [-.lib.module.build.t]xs.t ### Since not all tests were successful, you may want to run some of ### them individually and examine any diagnostic messages they produce. ### See the INSTALL document's section on "make test". u=6.97 s=0.00 cu=0.00 cs=0.00 scripts=1 tests=23 %SYSTEM-F-ABORT, abort
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
On Sat, Oct 04, 2008 at 01:55:50PM +1000, Adam Kennedy wrote: > The magic ponies will be introduced in 5.8.9 and 5.10.1. You indeed > will never have to upgrade. 5.8.9 will ship, ponies ready or not. I don't see stable ponies in blead to merge. I'm not the only person who can commit to blead, so someone else can deal with that part. Nicholas Clark
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
2008/10/3 Michael G Schwern <[EMAIL PROTECTED]>: >> 2008/9/30 Matt S Trout <[EMAIL PROTECTED]>: >>> If the world upgraded regularly, Module::Build wouldn't be such a disaster >>> anyway :) > > Adam Kennedy wrote: >> True, but it's FAR more palatable to say "Just upgrade ONCE, and >> you'll never have to think about it again" compared to upgrading >> continuously. > > As long as we're talking platitudes, why don't we just say you never have to > upgrade! In fact, you never even have to install the software, magic ponies > inside your computer will just know when you need it and go get it for you. > [1] The magic ponies will be introduced in 5.8.9 and 5.10.1. You indeed will never have to upgrade. Adam K
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
Michael G Schwern wrote: >> 2008/9/30 Matt S Trout <[EMAIL PROTECTED]>: >>> If the world upgraded regularly, Module::Build wouldn't be such a disaster >>> anyway :) > > Adam Kennedy wrote: >> True, but it's FAR more palatable to say "Just upgrade ONCE, and >> you'll never have to think about it again" compared to upgrading >> continuously. > > As long as we're talking platitudes, why don't we just say you never have to > upgrade! In fact, you never even have to install the software, magic ponies > inside your computer will just know when you need it and go get it for you. > [1] > > Also everyone gets a million dollars and a pet dragon. Sorry, that was a first-thing-in-the-morning post. I've totally lost track of the thread. -- 191. Our Humvees cannot be assembled into a giant battle-robot. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
> 2008/9/30 Matt S Trout <[EMAIL PROTECTED]>: >> If the world upgraded regularly, Module::Build wouldn't be such a disaster >> anyway :) Adam Kennedy wrote: > True, but it's FAR more palatable to say "Just upgrade ONCE, and > you'll never have to think about it again" compared to upgrading > continuously. As long as we're talking platitudes, why don't we just say you never have to upgrade! In fact, you never even have to install the software, magic ponies inside your computer will just know when you need it and go get it for you. [1] Also everyone gets a million dollars and a pet dragon. [1] I anticipate the Acme::Magic::Pony auto-installer on CPAN by Monday. -- 'All anyone gets in a mirror is themselves,' she said. 'But what you gets in a good gumbo is everything.' -- "Witches Abroad" by Terry Prachett
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
True, but it's FAR more palatable to say "Just upgrade ONCE, and you'll never have to think about it again" compared to upgrading continuously. Adam K 2008/9/30 Matt S Trout <[EMAIL PROTECTED]>: > If the world upgraded regularly, Module::Build wouldn't be such a disaster > anyway :)
Re: Module::Build 0.30 is released
On Tue, Sep 30, 2008 at 6:33 AM, Steve Hay <[EMAIL PROTECTED]> wrote: > Thanks, applied to bleadperl as 34446. > > Two local changes remain: > > Change 32357 by [EMAIL PROTECTED] on 2007/11/17 04:19:47 > >Skip Module::Build ppm test -- not ready for prime time on VMS. > > (ppm.t) > > Change 32351 by [EMAIL PROTECTED] on 2007/11/16 23:43:46 > >Silence ill-behaved or failing Module::Build tests on VMS. > > (test_type.t and xs.t parts only--the tilde.t part appears to have been > superseded by code in 0.30. Please can you check that, Craig?) I'll look into it. I think those were band-aids to expedite getting 5.10.0 out the door and what's coming from upstream now will fix at least some of the problems we had then.
RE: Module::Build 0.30 is released - ppm.t on VMS depends on Archive::Tar patch.
John E. Malmberg wrote: > Jos I. Boumans wrote: >> Hi John, >> >> On Oct 1, 2008, at 2:51 AM, John E. Malmberg wrote: >> >>> >>> http://www.nntp.perl.org/group/perl.vmsperl/2008/06/msg14821.html >>> >>> The main problem is that Archive::Tar needs a patch to properly be >>> able to pack a VMS binary into a tarball. >>> >>> We were waiting for word from Jos on this. >> >> It was my understanding that this was already applied to core, and >> it's also part of Archive::Tar 1.39_01: > > I just verified that the fix is not in blead perl as of today's rsync > copy just now. > > To be more specific it is a patch to Archive/Tar/File.pm to fix > handling of VMS binary executable files. It also fixes setting the > UID properly when saving the UID is requested. > >> http://search.cpan.org/src/KANE/Archive-Tar-1.39_04/CHANGES > > Yes I see that the patch is in the changelog. > >> A::T 1.39_04 looks stable, so we can promote it to 1.40 shortly. >> >> Is there anything specific you need me to do now? > > It looks like we need for blead to get more up to date. Blead is now updated to Archive-Tar-1.39_04 in #34452. One local change remains in blead: Change 32352 by [EMAIL PROTECTED] on 2007/11/16 23:46:13 The new Archive::Tar tests are TODO on VMS for reasons unrelated to the security issue for which they are testing. and I've just made another local change to fix a test that was failing after the upgrade: Change 34453 by [EMAIL PROTECTED] on 2008/10/01 16:55:42 Fix Archive-Tar's 02_methods.t when IO::Compress::Bzip2 is absent (We haven't got IO::Compress::Bzip2 in blead, and can_handle_compressed_files() checks for both IO::Zlib and IO::Compress::Bzip2, which caused test 1 to fail without this change. Hmm... Thinking some more (sadly *after* I just hit "submit", perhaps it would have been better to change test 1 to check against $ZLIB && $BZIP, rather than changing the meaning of $ZLIB?)
Re: Module::Build 0.30 is released - ppm.t on VMS depends on Archive::Tar patch.
On Wed, Oct 1, 2008 at 12:00 PM, Steve Hay <[EMAIL PROTECTED]> wrote: > Blead is now updated to Archive-Tar-1.39_04 in #34452. > > One local change remains in blead: > > Change 32352 by [EMAIL PROTECTED] on 2007/11/16 23:46:13 > >The new Archive::Tar tests are TODO on VMS for reasons unrelated >to the security issue for which they are testing. Well, that's a desperate-sounding and evasive commit message if I've ever seen one. And the evidence suggests I have seen this one. I'll take a look and see if the evasion is still necessary.
Re: Module::Build 0.30 is released - ppm.t on VMS depends on Archive::Tar patch.
Jos I. Boumans wrote: Hi John, On Oct 1, 2008, at 2:51 AM, John E. Malmberg wrote: http://www.nntp.perl.org/group/perl.vmsperl/2008/06/msg14821.html The main problem is that Archive::Tar needs a patch to properly be able to pack a VMS binary into a tarball. We were waiting for word from Jos on this. It was my understanding that this was already applied to core, and it's also part of Archive::Tar 1.39_01: I just verified that the fix is not in blead perl as of today's rsync copy just now. To be more specific it is a patch to Archive/Tar/File.pm to fix handling of VMS binary executable files. It also fixes setting the UID properly when saving the UID is requested. http://search.cpan.org/src/KANE/Archive-Tar-1.39_04/CHANGES Yes I see that the patch is in the changelog. A::T 1.39_04 looks stable, so we can promote it to 1.40 shortly. Is there anything specific you need me to do now? It looks like we need for blead to get more up to date. I also need to find the time to get the fix into gnu tar, because it is also mis-handling the VMS file sizes for executable binaries. Gnu tar also needs a fix for handling VMS GID values on creating an archive, which I also noticed when debugging this issue. As it is right now, A::T 1.39_04 is probably the only way to build a tarball on VMS that includes an executable binary. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Module::Build 0.30 is released - ppm.t on VMS depends on Archive::Tar patch.
Steve Hay wrote: Ken Williams wrote: Hi all, After much tireless work by Eric Wilhelm and lots of feedback from patient & nonpatient users alike, I'm pleased to announce that version 0.30 of Module::Build is now on CPAN. This is the first non-beta release in a long time. Thanks, applied to bleadperl as 34446. Two local changes remain: Change 32357 by [EMAIL PROTECTED] on 2007/11/17 04:19:47 Skip Module::Build ppm test -- not ready for prime time on VMS. http://www.nntp.perl.org/group/perl.vmsperl/2008/06/msg14821.html The main problem is that Archive::Tar needs a patch to properly be able to pack a VMS binary into a tarball. We were waiting for word from Jos on this. -John Personal Opinion Only
Re: Module::Build 0.30 is released - ppm.t on VMS depends on Archive::Tar patch.
Hi John, On Oct 1, 2008, at 2:51 AM, John E. Malmberg wrote: Steve Hay wrote: Ken Williams wrote: Hi all, After much tireless work by Eric Wilhelm and lots of feedback from patient & nonpatient users alike, I'm pleased to announce that version 0.30 of Module::Build is now on CPAN. This is the first non-beta release in a long time. Thanks, applied to bleadperl as 34446. Two local changes remain: Change 32357 by [EMAIL PROTECTED] on 2007/11/17 04:19:47 Skip Module::Build ppm test -- not ready for prime time on VMS. http://www.nntp.perl.org/group/perl.vmsperl/2008/06/msg14821.html The main problem is that Archive::Tar needs a patch to properly be able to pack a VMS binary into a tarball. We were waiting for word from Jos on this. It was my understanding that this was already applied to core, and it's also part of Archive::Tar 1.39_01: http://search.cpan.org/src/KANE/Archive-Tar-1.39_04/CHANGES A::T 1.39_04 looks stable, so we can promote it to 1.40 shortly. Is there anything specific you need me to do now? Cheers, -- Jos Boumans 'Real programmers use "cat > a.out"'
RE: Module::Build 0.30 is released
Ken Williams wrote: > Hi all, > > After much tireless work by Eric Wilhelm and lots of feedback from > patient & nonpatient users alike, I'm pleased to announce that version > 0.30 of Module::Build is now on CPAN. This is the first non-beta > release in a long time. Thanks, applied to bleadperl as 34446. Two local changes remain: Change 32357 by [EMAIL PROTECTED] on 2007/11/17 04:19:47 Skip Module::Build ppm test -- not ready for prime time on VMS. (ppm.t) Change 32351 by [EMAIL PROTECTED] on 2007/11/16 23:43:46 Silence ill-behaved or failing Module::Build tests on VMS. (test_type.t and xs.t parts only--the tilde.t part appears to have been superseded by code in 0.30. Please can you check that, Craig?) I've also just applied a new local change to fix compat.t, which was failing in my setup due to my having HARNESS_TIMER set to 1. I previously hacked around that in 33340, which was not taken up in 0.30, so hopefully this is better: Change 34447 by [EMAIL PROTECTED] on 2008/09/30 11:27:36 Fix Module-Build's compat.t when HARNESS_TIMER is set to 1 (compat.t)
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
On Mon, Sep 29, 2008 at 11:07:47AM -0400, David Golden wrote: > On Sun, Sep 28, 2008 at 9:54 PM, Adam Kennedy > <[EMAIL PROTECTED]> wrote: > > As far as I'm concerned, configure_requires doesn't exist until > > there's prod release of both CPAN.pm and CPANPLUS that support it. > > > > Once there is, THEN we can draw a line under it, call it done, and > > start recommending the use of Module::Build again. > > FYI -- CPAN.pm supports configure_requires since 1.92. > > So we're only waiting on CPANPLUS. And then we just need to wait a few years for the world to upgrade. If the world upgraded regularly, Module::Build wouldn't be such a disaster anyway :) -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
On Sun, Sep 28, 2008 at 04:16:33PM -0400, Michael G Schwern wrote: > Matt, I've met a lot of people who don't use Module::Build because you said > not to use it. They usually don't know why. There's already enough FUD > flying around without adding to it. Please either give us specifics we can > fix or stop it with the FUD. The specific is, and always has been, lack of autobundling which results in people having random releases. DBIx::Class doesn't have this issue because people can specify it in their Build/Makefile.PL and CPAN can handle it. Until configure_requires is widely deployed, say a couple years from now, that simply isn't the case for Build/Makefile.PL-time dependencies so autobundling is the sane workaround. As soon as Ken cuts a release with autobundling, I'll switch from "don't use it" to "if you use it, make sure you turn on autobundling unless you're damn sure all your users have configure_requires support". In the meantime, using Module::Build contravenes the "just fucking make it fucking easy to fucking install" rule which is why I recommend against it. Anyway, Ken's already given a perfectly logical reason for why autobundling isn't in this release and a statement that it will turn up soon, so this conversation is going to be moot very shortly anyway, happily. Again, KWILLIAMS++ > If you still insist on bundling Module::Build, you don't need Module::Build to > help you with that. Just do this: > > There, you have your bundling and a fuckton easier than in MakeMaker. use inc::Module::Install; is so much easier though. But hopefully the M::B bundling system will be just as easy, and then people can just use whichever they prefer. Me, I'm an old-school unix head and -like- Makefiles so I'll probably stick with M::I anyway at this point, but I'll make very clear at that point that that's a matter of taste on my part. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
Re: Module::Build 0.30 is released
On Sun, Sep 28, 2008 at 11:33:09AM -0500, Ken Williams wrote: > On Sun, Sep 28, 2008 at 8:38 AM, Matt S Trout <[EMAIL PROTECTED]> wrote: > > I was told it was a planned feature when KWILLIAMS turned up on london.pm > > and yelled "FUD" because I was complaining about users' problems in the > > real world rather than the problems of an ideal user that somehow magically > > knows that Module::Build is special and they have to remember to update it > > or installations will inexplicably fail. > > Can you show us that thread or a specific bug? The london.pm archive is searchable; I was complaining about now-fixed bugs that were still in the wild anyway - a response of "these are now fixed but it -is- a shame there's no easy way to force an update" would have been fine, I only took exception to having "FUD" yelled at me when I still encounter these problems regularly when supporting clients and OOS users. > Autobundling of M::B is indeed a planned feature. It's my personal > top priority. But we wanted to get "all the rest" of the work that's > been done in the last 1.5 years out the door before tackling it. And > autobundling is a nice special kind of feature that specifically > doesn't have to be tied to a major release schedule, so as long as we > get it out the door in a small amount of calendar time, people should > be happy. That's absolutely and perfectly logical, and I look forward to seeing it on CPAN. KWILLIAMS++ -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
On Sun, Sep 28, 2008 at 9:54 PM, Adam Kennedy <[EMAIL PROTECTED]> wrote: > As far as I'm concerned, configure_requires doesn't exist until > there's prod release of both CPAN.pm and CPANPLUS that support it. > > Once there is, THEN we can draw a line under it, call it done, and > start recommending the use of Module::Build again. FYI -- CPAN.pm supports configure_requires since 1.92. So we're only waiting on CPANPLUS. -- David
Re: Module::Build 0.30 is released
On Sunday 28 September 2008 06:38:44 Matt S Trout wrote: > Never mind, I'll go back to waiting for it to be five years from now and > the toolchain to have worked round this brain damage. That's not helpful. When a project doesn't release a new version, some people say "Oh, don't use it! They don't release new versions!" When a project does release a new version, some people say "Oh, don't use it! It's not perfect yet!" Meanwhile, the so-called reliable state of the art is a jumble of Perl which writes cross platform shell scripts to install Perl code, and you customize that by writing a superclass from which platform-specific modules inherit pseudo-methods which use regular expressions to search and replace cross-platform cross-shell code, with all of the cross-platform and cross-shell quoting issues that entails. I wish I were making any of this up. (I wrote tests for part of it.) This is why we can't have nice things. -- c
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
2008/9/29 Michael G Schwern <[EMAIL PROTECTED]>:
> Rather than a brute force "bundle your dependencies" there is now
> configure_requires. You can set configure_requires => { 'Module::Build' =>
> X.YY } in your Build.PL and an up-to-date CPAN shell will do the right thing.
> We've pressed hard to make sure all the build tools honor configure_requires.
> The CPAN shell has done it for a year now. CPANPLUS is still working on
> getting a stable release out, so if you want to help, help with that.
> Otherwise I don't want to hear about it.
As far as I'm concerned, configure_requires doesn't exist until
there's prod release of both CPAN.pm and CPANPLUS that support it.
Once there is, THEN we can draw a line under it, call it done, and
start recommending the use of Module::Build again.
Adam K
How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
Matt S Trout wrote:
> On Sat, Sep 27, 2008 at 07:53:07PM -0400, Michael G Schwern wrote:
>> Matt S Trout wrote:
>>> On Thu, Sep 25, 2008 at 10:01:19PM -0500, Ken Williams wrote:
Hi all,
After much tireless work by Eric Wilhelm and lots of feedback from
patient & nonpatient users alike, I'm pleased to announce that version
0.30 of Module::Build is now on CPAN. This is the first non-beta
release in a long time.
We did a *lot* of automated testing of third-party modules, with help
from various third party people like David Golden, to help minimize
any ill effects that might occur; nonetheless, if there are breakages
please let us know and we'll try to fix 'em.
>>> Can it bundle itself in inc/ yet or are you still expecting us to fix
>>> the entirety of the CPAN toolchain to work around cross-version breakages?
>> If something is broken, report it. If there's an unfixed bug that wasn't
>> handled, say so. If you want self-bundling, put it in the tracker and it
>> would be nice if you'd patch it.
>
> I was told it was a planned feature when KWILLIAMS turned up on london.pm
> and yelled "FUD" because I was complaining about users' problems in the
> real world rather than the problems of an ideal user that somehow magically
> knows that Module::Build is special and they have to remember to update it
> or installations will inexplicably fail.
>
> Never mind, I'll go back to waiting for it to be five years from now and the
> toolchain to have worked round this brain damage.
Ya know, wouldn't it be great if every time someone brought up DBIx::Class I
yelled about some old bug that bit me years ago and has long since been fixed
and told everyone to use Class::DBI? And then when ever anyone asked me for
specifics so they can be fixed I'd just get surly? Wouldn't that be great?
Matt, I've met a lot of people who don't use Module::Build because you said
not to use it. They usually don't know why. There's already enough FUD
flying around without adding to it. Please either give us specifics we can
fix or stop it with the FUD.
As to the issue of having the right version of Module::Build, we haven't been
idle, though as Ken pointed out there's far higher priority work to be done.
In the interest of actually solving your problem, rather than just bitching
about it in an abstract manner every once in a while, here's your options.
Rather than a brute force "bundle your dependencies" there is now
configure_requires. You can set configure_requires => { 'Module::Build' =>
X.YY } in your Build.PL and an up-to-date CPAN shell will do the right thing.
We've pressed hard to make sure all the build tools honor configure_requires.
The CPAN shell has done it for a year now. CPANPLUS is still working on
getting a stable release out, so if you want to help, help with that.
Otherwise I don't want to hear about it.
If you still insist on bundling Module::Build, you don't need Module::Build to
help you with that. Just do this:
1. Install Module::Build into Your-Dist/inc/Module-Build.
Use --install_base /path/to/Your-Dist/inc/Module-Build.
2. Put this at the top of your Build.PL
my $bundled_mb = 0.30; # or whatever it is
my $installed_mb = `$^X "-MModule::Build" -le "print Module::Build->VERSION"`;
chomp $installed_mb;
$installed_mb = 0 if $?;
unshift @INC, "inc/Module-Build/lib/perl5" if $bundled_mb > $installed_mb;
require Module::Build;
3. Use Module::Build as normal.
Module::Build will remember the change to @INC and propagate it through the
rest of the build steps.
There, you have your bundling and a fuckton easier than in MakeMaker. This
isn't rocket science, and I've seen you do rocket science. I came up with it
this morning, you've been bitching for years. Stop bitching, start thinking.
--
Reality is that which, when you stop believing in it, doesn't go away.
-- Phillip K. Dick
Re: Module::Build 0.30 is released
On Sat, Sep 27, 2008 at 07:53:07PM -0400, Michael G Schwern wrote: > Matt S Trout wrote: > > On Thu, Sep 25, 2008 at 10:01:19PM -0500, Ken Williams wrote: > >> Hi all, > >> > >> After much tireless work by Eric Wilhelm and lots of feedback from > >> patient & nonpatient users alike, I'm pleased to announce that version > >> 0.30 of Module::Build is now on CPAN. This is the first non-beta > >> release in a long time. > >> > >> We did a *lot* of automated testing of third-party modules, with help > >> from various third party people like David Golden, to help minimize > >> any ill effects that might occur; nonetheless, if there are breakages > >> please let us know and we'll try to fix 'em. > > > > Can it bundle itself in inc/ yet or are you still expecting us to fix > > the entirety of the CPAN toolchain to work around cross-version breakages? > > If something is broken, report it. If there's an unfixed bug that wasn't > handled, say so. If you want self-bundling, put it in the tracker and it > would be nice if you'd patch it. I was told it was a planned feature when KWILLIAMS turned up on london.pm and yelled "FUD" because I was complaining about users' problems in the real world rather than the problems of an ideal user that somehow magically knows that Module::Build is special and they have to remember to update it or installations will inexplicably fail. Never mind, I'll go back to waiting for it to be five years from now and the toolchain to have worked round this brain damage. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
Re: Module::Build 0.30 is released
Matt S Trout wrote: > On Thu, Sep 25, 2008 at 10:01:19PM -0500, Ken Williams wrote: >> Hi all, >> >> After much tireless work by Eric Wilhelm and lots of feedback from >> patient & nonpatient users alike, I'm pleased to announce that version >> 0.30 of Module::Build is now on CPAN. This is the first non-beta >> release in a long time. >> >> We did a *lot* of automated testing of third-party modules, with help >> from various third party people like David Golden, to help minimize >> any ill effects that might occur; nonetheless, if there are breakages >> please let us know and we'll try to fix 'em. > > Can it bundle itself in inc/ yet or are you still expecting us to fix > the entirety of the CPAN toolchain to work around cross-version breakages? If something is broken, report it. If there's an unfixed bug that wasn't handled, say so. If you want self-bundling, put it in the tracker and it would be nice if you'd patch it. Don't play this sort of passive/aggressive BS. It's childish and unproductive. -- "Clutter and overload are not an attribute of information, they are failures of design" -- Edward Tufte
Re: Module::Build 0.30 is released
On Sun, Sep 28, 2008 at 8:38 AM, Matt S Trout <[EMAIL PROTECTED]> wrote: > I was told it was a planned feature when KWILLIAMS turned up on london.pm > and yelled "FUD" because I was complaining about users' problems in the > real world rather than the problems of an ideal user that somehow magically > knows that Module::Build is special and they have to remember to update it > or installations will inexplicably fail. Can you show us that thread or a specific bug? Autobundling of M::B is indeed a planned feature. It's my personal top priority. But we wanted to get "all the rest" of the work that's been done in the last 1.5 years out the door before tackling it. And autobundling is a nice special kind of feature that specifically doesn't have to be tied to a major release schedule, so as long as we get it out the door in a small amount of calendar time, people should be happy. -Ken
Re: Module::Build 0.30 is released
On Thu, Sep 25, 2008 at 10:01:19PM -0500, Ken Williams wrote: > Hi all, > > After much tireless work by Eric Wilhelm and lots of feedback from > patient & nonpatient users alike, I'm pleased to announce that version > 0.30 of Module::Build is now on CPAN. This is the first non-beta > release in a long time. > > We did a *lot* of automated testing of third-party modules, with help > from various third party people like David Golden, to help minimize > any ill effects that might occur; nonetheless, if there are breakages > please let us know and we'll try to fix 'em. Can it bundle itself in inc/ yet or are you still expecting us to fix the entirety of the CPAN toolchain to work around cross-version breakages? -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
