Thread: Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in (Page 2)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Chris D. <ch...@cl...> - 2006-02-14 21:04:33
|
On Feb 14, 2006, at 2:40 PM, Tyler MacDonald wrote: > Well it would only clobber the file if it contained the > "auto-generated" line, so I think that's safe, but if you want to be > *really* paranoid, how about having the dist actions fail if you > havent > specified a "create_makfile_pl" arg? (one of the exsitng ones or > "skip"). I just tested and CVS HEAD M::B happily overwrote a hand-made Makefile.PL when I added 'traditional' to Build.PL and ran "Build distdir". Luckily, I had it in SVN so it was an easy restore. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) |
|
From: Tyler M. <ty...@yi...> - 2006-02-14 21:07:09
|
Chris Dolan <ch...@cl...> wrote: > > Well it would only clobber the file if it contained the > >"auto-generated" line, so I think that's safe, but if you want to be > >*really* paranoid, how about having the dist actions fail if you havent > >specified a "create_makfile_pl" arg? (one of the exsitng ones or "skip"). > I just tested and CVS HEAD M::B happily overwrote a hand-made > Makefile.PL when I added 'traditional' to Build.PL and ran "Build > distdir". Luckily, I had it in SVN so it was an easy restore. But that's exactly what you asked it to do. ;-) Seriously though, it sounds like having at least a loud warning "I did not write this Makefile.PL, move it out of the way first" is worthwhile. - Tyler |
|
From: John P. <jpe...@ro...> - 2006-02-14 21:18:19
|
Tyler MacDonald wrote:
> Seriously though, it sounds like having at least a loud warning "I
> did not write this Makefile.PL, move it out of the way first" is worthwhile.
Pseudocode:
if ($mb->overwrite_makefile() && -f $Makefile ) {
my $answer = $mb->y_n("Found an existing Makefile.PL; overwrite?");
if ($answer =~/y/i) {
write_makefile;
}
}
where overwrite_makefile is a package option passed to M::B::new(). I
did it this way so that
a) the developer has to affirmatively choose that option;
b) the developer has to _always_ hit 'Y' when running './Build distdir',
just in case he/she did something manually and forgot to turn off the
option.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
|
|
From: Tyler M. <ty...@yi...> - 2006-02-14 21:20:57
|
John Peacock <jpe...@ro...> wrote:
> if ($mb->overwrite_makefile() && -f $Makefile ) {
> my $answer = $mb->y_n("Found an existing Makefile.PL; overwrite?");
> if ($answer =~/y/i) {
> write_makefile;
> }
> }
>
> where overwrite_makefile is a package option passed to M::B::new(). I
> did it this way so that
>
> a) the developer has to affirmatively choose that option;
> b) the developer has to _always_ hit 'Y' when running './Build distdir',
> just in case he/she did something manually and forgot to turn off the
> option.
So that's in there now?
BTW.. tsk tsk... y_n requires a default now. ;-)
- Tyler
|
|
From: Chris D. <ch...@cl...> - 2006-02-14 21:22:36
|
On Feb 14, 2006, at 3:18 PM, John Peacock wrote:
> Tyler MacDonald wrote:
>> Seriously though, it sounds like having at least a loud warning "I
>> did not write this Makefile.PL, move it out of the way first" is
>> worthwhile.
>
> Pseudocode:
>
> if ($mb->overwrite_makefile() && -f $Makefile ) {
> my $answer = $mb->y_n("Found an existing Makefile.PL;
> overwrite?");
> if ($answer =~/y/i) {
> write_makefile;
> }
> }
>
> where overwrite_makefile is a package option passed to M::B::new
> (). I did it this way so that
>
> a) the developer has to affirmatively choose that option;
> b) the developer has to _always_ hit 'Y' when running './Build
> distdir', just in case he/she did something manually and forgot to
> turn off the option.
Ugh, I have to hit "Y" every time??? If you add the following to the
conditional, I'd be happy:
&& slurp($Makefile) !~ /auto.generated/is
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
|
|
From: Chris D. <ch...@cl...> - 2006-02-14 21:19:29
|
On Feb 14, 2006, at 3:06 PM, Tyler MacDonald wrote: > Chris Dolan <ch...@cl...> wrote: >>> Well it would only clobber the file if it contained the >>> "auto-generated" line, so I think that's safe, but if you want to be >>> *really* paranoid, how about having the dist actions fail if you >>> havent >>> specified a "create_makfile_pl" arg? (one of the exsitng ones or >>> "skip"). >> I just tested and CVS HEAD M::B happily overwrote a hand-made >> Makefile.PL when I added 'traditional' to Build.PL and ran "Build >> distdir". Luckily, I had it in SVN so it was an easy restore. > > But that's exactly what you asked it to do. ;-) > > Seriously though, it sounds like having at least a loud warning "I > did not write this Makefile.PL, move it out of the way first" is > worthwhile. > > - Tyler I understand that. I was simply saying that your assertion that it wouldn't clobber a file that lacked the "auto-generated" line was not the current reality. It was unclear to me from that message whether you were discussing actual behavior or ideal behavior, so I tested it myself. Sorry, I should have put a smiley after my SVN comment. :-D I like your proposed warning. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) |
|
From: Tyler M. <ty...@yi...> - 2006-02-14 21:23:09
|
Chris Dolan <ch...@cl...> wrote: > >>> Well it would only clobber the file if it contained the > >>>"auto-generated" line, so I think that's safe, but if you want to be > >>>*really* paranoid, how about having the dist actions fail if you > >>>havent > >>>specified a "create_makfile_pl" arg? (one of the exsitng ones or > >>>"skip"). > >>I just tested and CVS HEAD M::B happily overwrote a hand-made > >>Makefile.PL when I added 'traditional' to Build.PL and ran "Build > >>distdir". Luckily, I had it in SVN so it was an easy restore. > > > > But that's exactly what you asked it to do. ;-) > > > > Seriously though, it sounds like having at least a loud warning "I > >did not write this Makefile.PL, move it out of the way first" is > >worthwhile. > > > > - Tyler > > I understand that. I was simply saying that your assertion that it > wouldn't clobber a file that lacked the "auto-generated" line was not > the current reality. It was unclear to me from that message whether > you were discussing actual behavior or ideal behavior, so I tested it > myself. Sorry, I should have put a smiley after my SVN comment. :-D Heh. This is all proposed behaviour. Everybody seems to agree the current behaviour isn't ideal, so before I write a patch (looks like John Peacock might have beat me too it anyway) I just wanted to be clear on the solution. Bitching about an existing Makefile.PL seems to be the lowest common denominator among all the ideas that have gone back and forth, so that should definately be implemented first. What's still in the air; - Whether or not we check for the "auto-generated by MB::Compat" line - Whether or not we add an explicit 'skip' argument to create_makefile_pl, which follows through to; - Whether or not we complain and/or fail to function if the module developer has not specified "create_makefile_pl" at all. Cheers, Tyler |
|
From: Ken W. <ke...@ma...> - 2006-02-16 17:40:24
|
On Feb 14, 2006, at 1:16 PM, Tyler MacDonald wrote: > Ken Williams <ke...@ma...> wrote: >> If we did that, we'd screw over people who are already maintaining >> their Makefile.PL separately by hand. > > OK... but if they are doing that, the Makefile.PL will be in their > *build* directory already... as far as I understand, our Makefile.PL > only > needs to be generated in the *dist* directory. Yeah, that's true. Let me reconsider my reasoning here from scratch. The original point that Adam & Yves were making, IIUIC, was that distributions should include a Makefile.PL. If they don't have one at all, then of course we don't need to worry about clobbering one! So I'd be fine with changing the default in this case to provide some flavor of Makefile.PL generated in the dist directory. The main question would be what style to make it. 'traditional' is accessible by more people, but will often be broken (if, e.g., there are config questions or auto-sensing in the Build.PL they'll be lost to the Makefile.PL), so I'd be inclined to choose 'small' or 'passthrough' for this case. That should make most people happy, no? -Ken |
|
From: Tyler M. <ty...@yi...> - 2006-02-16 17:46:10
|
Ken Williams <ke...@ma...> wrote: > >*build* directory already... as far as I understand, our Makefile.PL only > >needs to be generated in the *dist* directory. > > Yeah, that's true. > > Let me reconsider my reasoning here from scratch. The original point > that Adam & Yves were making, IIUIC, was that distributions should > include a Makefile.PL. If they don't have one at all, then of course > we don't need to worry about clobbering one! So I'd be fine with > changing the default in this case to provide some flavor of Makefile.PL > generated in the dist directory. > > The main question would be what style to make it. 'traditional' is > accessible by more people, but will often be broken (if, e.g., there > are config questions or auto-sensing in the Build.PL they'll be lost to > the Makefile.PL), so I'd be inclined to choose 'small' or 'passthrough' > for this case. I think "passthrough" is the way to go here. I also still think that if we default in some way to generating a Makefile.PL, create_makefile_pl should be extended to have an explicit "skip" option as well. > That should make most people happy, no? Sounds good to me. :-) - Tyler |
|
From: Ken W. <ke...@ma...> - 2006-02-16 17:54:27
|
On Feb 16, 2006, at 11:45 AM, Tyler MacDonald wrote: > I think "passthrough" is the way to go here. I also still think that > if we default in some way to generating a Makefile.PL, > create_makefile_pl > should be extended to have an explicit "skip" option as well. Definitely. I'd just change the default to 'auto' (which means create a 'small' [or 'passthrough'] Makefile.PL if none already exists) though, and then the author can explicitly put "create_makefile_pl => 0" (or any other false value) in their Build.PL to shut it off. If in the future we figure out how to auto-sense when we could create a 'traditional' Makefile.PL that would be cool, but I don't really see it happening. Too hard. -Ken |
|
From: Chris D. <ch...@cl...> - 2006-02-16 20:05:35
Attachments:
simple_build_pl
|
On Feb 16, 2006, at 11:53 AM, Ken Williams wrote: > On Feb 16, 2006, at 11:45 AM, Tyler MacDonald wrote: > >> I think "passthrough" is the way to go here. I also still think that >> if we default in some way to generating a Makefile.PL, >> create_makefile_pl >> should be extended to have an explicit "skip" option as well. > > Definitely. I'd just change the default to 'auto' (which means > create a 'small' [or 'passthrough'] Makefile.PL if none already > exists) though, and then the author can explicitly put > "create_makefile_pl => 0" (or any other false value) in their > Build.PL to shut it off. > > If in the future we figure out how to auto-sense when we could > create a 'traditional' Makefile.PL that would be cool, but I don't > really see it happening. Too hard. > > -Ken Attached below is a regexp-based solution that matches "simple" Build.PL files. I submit this just for thought, not necessarily for inclusion in M::B. Inline below are the results of running my program against a bunch of CPAN packages. This demonstrates that many CPAN modules use "simple" Build.PL files. If (and that's a big if) we decided to use a code- matcher like what I've written, we could detect simple Build.PL files and decide on the fly if a "traditional" Makefile.PL is appropriate. Perhaps this mode could be triggered by C<create_makefile_pl => 'automatic'> One could imagine that PPI would be a good tool to perform this code analysis. % perl simple_build_pl ~/.cpanplus/5.8.6/build/*/Build.PL simple Array-Compare-1.13/Build.PL simple CAM-DBF-1.01/Build.PL simple CAM-EmailTemplate-SMTP-0.91/Build.PL complex CAM-PDF-1.03/Build.PL simple CAM-SQLManager-1.13/Build.PL simple CAM-SQLObject-1.01/Build.PL simple CAM-Session-1.03/Build.PL simple CAM-Template-0.93/Build.PL simple CAM-Template-Cache-0.91/Build.PL simple CAM-XML-1.13/Build.PL simple CGI-Compress-Gzip-0.21/Build.PL simple Class-Accessor-Chained-0.01/Build.PL simple Class-Std-0.0.4/Build.PL simple Config-Std-0.0.2/Build.PL complex DateTime-Locale-0.22/Build.PL complex DateTime-TimeZone-0.40/Build.PL simple Devel-StackTrace-1.12/Build.PL simple Exception-Class-1.23/Build.PL simple ExtUtils-CBuilder-0.15/Build.PL simple FSA-Rules-0.23/Build.PL complex File-Extract-0.06/Build.PL simple File-Find-Rule-0.28/Build.PL simple File-Find-Rule-Filesys-Virtual-1.21/Build.PL simple HTTP-Proxy-0.17/Build.PL complex Image-Imlib2-1.07/Build.PL complex Module-Build-0.27_06/Build.PL simple Module-CPANTS-Analyse-0.5/Build.PL simple Module-CPANTS-Generator-0.42/Build.PL simple Module-Depends-0.10/Build.PL simple Module-ExtractUse-0.17/Build.PL simple Module-Pluggable-2.96/Build.PL simple Module-Starter-PBP-0.0.2/Build.PL simple Net-DAV-Server-1.28/Build.PL simple Net-IP-Match-Regexp-0.93/Build.PL simple Net-VNC-0.30/Build.PL simple Parse-CPAN-Modlist-0.9/Build.PL simple Parse-CPAN-Packages-2.25/Build.PL simple Path-Class-0.15/Build.PL complex PathTools-3.15/Build.PL simple Perl-Critic-0.13/Build.PL simple Perl-Metric-Basic-0.30/Build.PL simple Pod-Coverage-0.17/Build.PL simple Pod-FromActionscript-0.53/Build.PL simple Pod-Readme-0.05/Build.PL simple Pod-Strip-1.01/Build.PL simple SWF-NeedsRecompile-1.02/Build.PL simple Test-Distribution-1.23/Build.PL simple Test-Exception-0.21/Build.PL simple Test-MockObject-1.02/Build.PL simple Test-Perl-Critic-0.03/Build.PL simple UNIVERSAL-can-1.03/Build.PL simple UNIVERSAL-isa-0.05/Build.PL complex version-0.53/Build.PL Interestingly, two of the "complex" results were false positives because of typos in the Build.PL -- the file contained "author" instead of "dist_author" Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) |
|
From: Ken W. <ke...@ma...> - 2006-02-16 21:03:38
|
On Feb 16, 2006, at 2:05 PM, Chris Dolan wrote: > Attached below is a regexp-based solution that matches "simple" > Build.PL files. I submit this just for thought, not necessarily for > inclusion in M::B. Cool. I wonder if Randy Sims (when he gets back from vacation) could run this against his mini-cpan area to get some statistics on the broader CPAN. Or anyone else, if they're so inclined, certainly. > Perhaps this mode could be triggered by C<create_makefile_pl => > 'automatic'> Yeah. As long as we're very strict in how we parse, i.e. any "syntax errors" according to our grammar for simple Build.PL files are "fatal", this does seem like a good way to do things. I would initially like to roll out the 'auto' default without any of this sensing on the Build.PL, but it's going to be good to have in our back pocket. Thanks. -Ken |
|
From: Randy W. S. <ml...@th...> - 2006-02-24 11:50:17
|
Ken Williams wrote: > > On Feb 16, 2006, at 2:05 PM, Chris Dolan wrote: > >> Attached below is a regexp-based solution that matches "simple" >> Build.PL files. I submit this just for thought, not necessarily for >> inclusion in M::B. > > > Cool. I wonder if Randy Sims (when he gets back from vacation) could > run this against his mini-cpan area to get some statistics on the > broader CPAN. Or anyone else, if they're so inclined, certainly. I've extended the script a bit at: <http://thepierianspring.org/perl/meta/> I'm not at all sure about the results of the simple/complex scan, or my integration of that code... I've converted to html. Nothing pretty; I'm not a web guy. But there are now links, so you can drill down in to see what distribution is doing what, including links back to the original source file (META.yml, etc) on CPAN. Some of the "Installers" (as determined by the generated_by field in META.yml) need to be grouped under misc, to clean up things. Also, there a some links that don't work because of some decisions I made back when this was just a ~60-80 one-off script to find out how META.yml was being used. Randy. |
|
From: demerphq <dem...@gm...> - 2006-02-16 21:48:18
|
On 2/16/06, Ken Williams <ke...@ma...> wrote: > Let me reconsider my reasoning here from scratch. The original point > that Adam & Yves were making, IIUIC, was that distributions should > include a Makefile.PL. If they don't have one at all, then of course > we don't need to worry about clobbering one! So I'd be fine with > changing the default in this case to provide some flavor of Makefile.PL > generated in the dist directory. Yes that was my point. > The main question would be what style to make it. 'traditional' is > accessible by more people, but will often be broken (if, e.g., there > are config questions or auto-sensing in the Build.PL they'll be lost to > the Makefile.PL), so I'd be inclined to choose 'small' or 'passthrough' > for this case. > > That should make most people happy, no? In general yes. But I think its worth considering that traditional is preferable. This http://perlmonks.org/index.pl?node_id=3D458282 argues that the traditional provides more flexibility for the end user. Cheers, yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: Ken W. <ke...@ma...> - 2006-02-16 21:54:35
|
On Feb 16, 2006, at 3:48 PM, demerphq wrote: > In general yes. But I think its worth considering that traditional is > preferable. This > > http://perlmonks.org/index.pl?node_id=458282 > > argues that the traditional provides more flexibility for the end user. Yes. -Ken |
|
From: Tyler M. <ty...@yi...> - 2006-02-16 22:04:01
|
demerphq <dem...@gm...> wrote: > > That should make most people happy, no? > > In general yes. But I think its worth considering that traditional is > preferable. This > > http://perlmonks.org/index.pl?node_id=458282 > > argues that the traditional provides more flexibility for the end user. I think that argument is better solved by making Module::Build::Compat should a bit more compatible. The main argument this guy makes is that these modules aren't even using Module::Build's cool new functionality... - Tyler |
|
From: Ken W. <ke...@ma...> - 2006-02-14 18:16:44
|
On Feb 14, 2006, at 11:16 AM, demerphq wrote: > My understanding of this (and i hope im not putting words in Adams > mouth) is that anybody using an old CPAN can't install a distribution > that requires Module::Build unless a Makefile.PL is present. Right. > Since this is a big chunk of the cpan's out there it affects a lot of > users, > and in my experience is one of the reasons that people often get a bad > impression of MB on their first exposure as there is a good chance > that the first time they notice something uses MB will be when CPAN > fails to install because of the missing Makefile.pl Agreed. > IOW, no dist should ever be released to CPAN without a Makefile.PL and > MB should not allow anyone to create such a dist. I personally agree, but I'd rather implement it as a sanity check rather than a forced decision - something like, during the 'dist' action: "you're about to create a distribution that contains no Makefile.PL. This will limit the ability of CPAN users to install your module. Are you sure you want to continue?" If they answer no (or heck, even if they answer yes), we can point them to the documentation for Module::Build::Compat so they can auto-generate an appropriate Makefile.PL. -Ken |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-02-17 03:26:54
|
On Thu, Feb 16, 2006 at 02:07:50PM +0100, Rafael Garcia-Suarez wrote: > On 2/16/06, demerphq <dem...@gm...> wrote: > > ps: I'll go out on a limb here and say that MB should NOT be made core > > until it makes Makefile.PL production mandatory. And until it can That doesn't make sense to me. Alerting module authors to missing Makefile.PLs is important only because of how many MB-less installations there are out there; adding MB to the core can only end up decreasing the number of such installations. > My opinion : the functionality that's interesting to add in the core > is to be able to run Build.PL, not to produce distros. Agreed, but there's little point in separating them. > On the other hand, if we begin to ship M::B with stable perls, a lot > of people will keep perl's M::B and not upgrade it. So we'd better be > sure it's pretty stable in terms of functionality and API. So I agree > with you here. Um. Those same people aren't likely to install M::B in the first place. I don't see how providing them with it (even if it will fall out of date) hurts. With respect to stability, I hope functionality continues to increase, and that backwards-incompatible changes will be severely limited. I don't see how this is different from any other module already in the core. However, I hope you are only applying this reasoning to 5.8.x. My main reason for wanting M::B in the core for 5.9.x as soon as possible is to increase the number of people forced to test it and help get it working on non-major platforms. |
|
From: Nicholas C. <ni...@cc...> - 2006-02-17 14:01:47
|
On Wed, Feb 15, 2006 at 12:07:02PM +0100, Rafael Garcia-Suarez wrote: > On 2/15/06, Adam Kennedy <cp...@al...> wrote: > > But MB is going to go core real soon now though right? 5.8.9? > > It's planned for the next 5.9, but I doubt new modules will go in the > maintainance track. (But I'm no authority on maint:) Well, I was assuming that it would be in current stable when current stable is 5.10 :-) (ie no, not 5.8.x, for the reasons below) On Thu, Feb 16, 2006 at 07:26:47PM -0800, Yitzchak Scott-Thoennes wrote: > On Thu, Feb 16, 2006 at 02:07:50PM +0100, Rafael Garcia-Suarez wrote: > > On the other hand, if we begin to ship M::B with stable perls, a lot > > of people will keep perl's M::B and not upgrade it. So we'd better be > > sure it's pretty stable in terms of functionality and API. So I agree > > with you here. > > Um. Those same people aren't likely to install M::B in the first place. > I don't see how providing them with it (even if it will fall out of date) > hurts. It won't hurt them, but it will cause immense pain for anyone wanting to ship a module that uses a Build.PL - those developers will be forced to decide whether to cut out anyone with an old Module::Build, or code their Build.PL to use that version and work around the deficiencies. The thread on what YAML version Module::Build needs, and how to upgrade correctly if there isn't >=0.50 suggests that solving these "Module::Build needs upgrading" issues isn't yet battle tested. This is fine for 5.9 (anyone using 5.9 should be expecting surprises, including unannounced binary compatibility breakages across any patch) but not for stable, be it 5.8.x or 5.10.1. There is time before 5.10 to solve this. [But hopefully not loads of time :-)] > With respect to stability, I hope functionality continues to increase, > and that backwards-incompatible changes will be severely limited. I > don't see how this is different from any other module already in the > core. > > However, I hope you are only applying this reasoning to 5.8.x. My That's why it's not suitable for "stable" now, independent of any policy on assimilation. Nicholas Clark |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-02-19 04:12:53
|
On Fri, Feb 17, 2006 at 02:01:30PM +0000, Nicholas Clark wrote: > On Thu, Feb 16, 2006 at 07:26:47PM -0800, Yitzchak Scott-Thoennes wrote: > > On Thu, Feb 16, 2006 at 02:07:50PM +0100, Rafael Garcia-Suarez wrote: > > > > On the other hand, if we begin to ship M::B with stable perls, a lot > > > of people will keep perl's M::B and not upgrade it. So we'd better be > > > sure it's pretty stable in terms of functionality and API. So I agree > > > with you here. > > > > Um. Those same people aren't likely to install M::B in the first place. > > I don't see how providing them with it (even if it will fall out of date) > > hurts. > > It won't hurt them, but it will cause immense pain for anyone wanting to > ship a module that uses a Build.PL - those developers will be forced to > decide whether to cut out anyone with an old Module::Build, or code their > Build.PL to use that version and work around the deficiencies. I don't see the mountain, just a molehill. But maybe that's just me. For (wild speculation in absense of data) 99% of modules, Module::Build is feature-complete. The remaining 1% of modules (e.g. Tk) won't be switching to it any time soon, and when they do, they'll require version 0.30 or the like. > The thread on what YAML version Module::Build needs, and how to upgrade > correctly if there isn't >=0.50 suggests that solving these "Module::Build > needs upgrading" issues isn't yet battle tested. I missed that thread. What was the subject? Module::Build doesn't need YAML at all (though authors really should have it to generate a fleshed-out META.yml). And the current development version should work fine with current versions of YAML. I don't think anybody is suggesting putting 0.2611 in the core, and I for one wouldn't mind seeing the battle-testing that would result from putting 0.27_* in the core happen before 0.28 is released. > This is fine for 5.9 (anyone using 5.9 should be expecting surprises, > including unannounced binary compatibility breakages across any patch) > but not for stable, be it 5.8.x or 5.10.1. > There is time before 5.10 to solve this. [But hopefully not loads of time :-)] > > With respect to stability, I hope functionality continues to increase, > > and that backwards-incompatible changes will be severely limited. I > > don't see how this is different from any other module already in the > > core. > > > > However, I hope you are only applying this reasoning to 5.8.x. My > > That's why it's not suitable for "stable" now, independent of any policy > on assimilation. Disagreeing with the premise (assuming I've correctly identified your "That"), I disagree with your conclusion too. Oh well. |
|
From: John P. <jpe...@ro...> - 2006-02-19 15:54:27
|
Yitzchak Scott-Thoennes wrote: > On Fri, Feb 17, 2006 at 02:01:30PM +0000, Nicholas Clark wrote: >> The thread on what YAML version Module::Build needs, and how to upgrade >> correctly if there isn't >=0.50 suggests that solving these "Module::Build >> needs upgrading" issues isn't yet battle tested. > > I missed that thread. What was the subject? Here the thread (it started on the YAML list): http://tinyurl.com/barey (I can't figure out how to get Mailman to show the thread properly). > Module::Build doesn't > need YAML at all (though authors really should have it to generate a > fleshed-out META.yml). And the current development version should > work fine with current versions of YAML. It's a little more complicated than that. M::B 0.2611 cannot be installed with YAML support unless YAML is >= 0.35 and < 0.49 (it's an autofeature). However if you reinstall YAML 0.58 after you install M::B, then everything still works. If M::B 0.28 required YAML 0.58 for the YAML feature to be auto-enabled, and the author had not already upgraded YAML, then the YAML feature would be disabled without much in the way of warning. It still wouldn't affect the users (who don't need YAML at all). However, this has just given me an idea: Bundle::Module::Build::Authors. This would install all of the "recommends" modules as well as the latest YAML. In any case, I've recommended that the version.pm support be pulled out of consideration for 0.28, due to these complications. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747 |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-06 20:59:39
|
On Sat, Feb 25, 2006 at 02:53:49PM -0600, Ken Williams wrote: > > On Feb 19, 2006, at 12:00 AM, Adam Kennedy wrote: > > > > >And if we can clear Module::Build on 400-500 installations of Perl, > >I'd feel much more comfortable about seeing it head towards the core. > > Holy crap! Is this really the litmus test for core inclusion these > days? Do we apply that standard to all modules? It certainly wasn't > done for ExtUtils::ParseXS or ExtUtils::CBuilder (both of which were > offshoots of the Module::Build project). They were just deemed to be > helpful additions with reasonable interfaces, so they were added. > I'd hope that same standard would apply here. Rafael applied my patch to add 0.27_08 to the core today. |
|
From: Ken W. <ke...@ma...> - 2006-03-06 21:08:43
|
On Mar 6, 2006, at 2:59 PM, Yitzchak Scott-Thoennes wrote: > > Rafael applied my patch to add 0.27_08 to the core today. > Our day of reckoning is here! =) Presumably this means we'll get lots of bug reports as people do their smoke testing. We'll have to be judicious about which bugs we fix before 0.28 and which ones we don't, or else we'll never get 0.28 out the door. I think probably only show-stopping bugs should get fixed, and others can be listed as "known bugs" or whatever so people know not to rely on them as behaviors. Yizchak, thanks for generating all your patches. That's a big help for getting the integration to happen. -Ken |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-06 21:10:12
|
On Mon, Mar 06, 2006 at 03:08:31PM -0600, Ken Williams wrote: > > On Mar 6, 2006, at 2:59 PM, Yitzchak Scott-Thoennes wrote: > > > > >Rafael applied my patch to add 0.27_08 to the core today. > > > > Our day of reckoning is here! =) > > Presumably this means we'll get lots of bug reports as people do > their smoke testing. We'll have to be judicious about which bugs we > fix before 0.28 and which ones we don't, or else we'll never get 0.28 > out the door. I think probably only show-stopping bugs should get > fixed, and others can be listed as "known bugs" or whatever so people > know not to rely on them as behaviors. > > Yizchak, thanks for generating all your patches. That's a big help > for getting the integration to happen. I'm hoping most of the trouble will be problems in the test framework, and that we can fix those even if not show-stopping for most platforms. |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-07 16:00:16
|
On Mon, Mar 06, 2006 at 01:10:02PM -0800, Yitzchak Scott-Thoennes wrote: > On Mon, Mar 06, 2006 at 03:08:31PM -0600, Ken Williams wrote: > > > > On Mar 6, 2006, at 2:59 PM, Yitzchak Scott-Thoennes wrote: > > > > > > > >Rafael applied my patch to add 0.27_08 to the core today. > > > > > > > Our day of reckoning is here! =) > > > > Presumably this means we'll get lots of bug reports as people do > > their smoke testing. We'll have to be judicious about which bugs we > > fix before 0.28 and which ones we don't, or else we'll never get 0.28 > > out the door. I think probably only show-stopping bugs should get > > fixed, and others can be listed as "known bugs" or whatever so people > > know not to rely on them as behaviors. > > > > Yizchak, thanks for generating all your patches. That's a big help > > for getting the integration to happen. > > I'm hoping most of the trouble will be problems in the test framework, > and that we can fix those even if not show-stopping for most platforms. Clarification: I mean that I hope even non-show-stopping patches can get applied pre-0.28. Those working on getting 0.28 out should keep on at that and try not to get too distracted. |
Thanks for helping keep SourceForge clean.
X