Re: [Module::Build] Re: Test::META

2005-04-01 Thread Ken Williams
On Apr 1, 2005, at 2:55 PM, Christopher H. Laco wrote: If build, test, and install are considered the critical path, why was Build/make never changed to simple run "test" always as part of the builds success or failure? Just curious. In a way, I'd be much happier if 'perl Build' or 'make' outri

Re: [Module::Build] Re: Test::META

2005-04-01 Thread David Golden
Ken Williams wrote: On Mar 30, 2005, at 6:16 PM, Michael G Schwern wrote: On Wed, Mar 30, 2005 at 05:53:37PM -0500, Randy W. Sims wrote: Should we completely open this up so that requires/recommends/conflicts can be applied to any action? install_recommends => ... testcover_requires => ... etc. Th

Re: [Module::Build] Re: Test::META

2005-04-01 Thread Christopher H. Laco
Ken Williams wrote: Since the 'build', 'test', and 'install' actions are considered the "critical path" for installing a module, I think it makes sense to warn (not die) during "perl Build.PL" when one of their required/recommended/conflict dependencies aren't met. Thereafter, only die/warn wh

Re: [Module::Build] Re: Test::META

2005-04-01 Thread Ken Williams
On Mar 29, 2005, at 10:44 PM, Randy W. Sims wrote: Michael G Schwern wrote: On Tue, Mar 29, 2005 at 08:33:48PM -0500, Randy W. Sims wrote: A quickie sample implementation to add more meat. I didn't apply yet mainly because I'm wondering if we shouldn't bail and do a complete roll-back (eg. don't

Re: [Module::Build] Re: Test::META

2005-04-01 Thread Ken Williams
On Mar 30, 2005, at 6:16 PM, Michael G Schwern wrote: On Wed, Mar 30, 2005 at 05:53:37PM -0500, Randy W. Sims wrote: Should we completely open this up so that requires/recommends/conflicts can be applied to any action? install_recommends => ... testcover_requires => ... etc. This sounds useful an

Re: [Module::Build] Re: Test::META

2005-03-30 Thread Michael G Schwern
On Wed, Mar 30, 2005 at 05:53:37PM -0500, Randy W. Sims wrote: > Should we completely open this up so that requires/recommends/conflicts > can be applied to any action? > > install_recommends => ... > testcover_requires => ... > etc. This sounds useful and solves a lot of problems at one sweep.

Re: [Module::Build] Re: Test::META

2005-03-30 Thread Ken Williams
On Mar 30, 2005, at 4:53 PM, Randy W. Sims wrote: Should we completely open this up so that requires/recommends/conflicts can be applied to any action? install_recommends => ... testcover_requires => ... etc. I like it. But for some reason I find it a little scary. Doing this would require a lit

Re: [Module::Build] Re: Test::META

2005-03-30 Thread Randy W. Sims
Ken Williams wrote: On a related note, we should probably finally make the prerequisite-specification system treat the requirement level (requires vs. recommends vs. conflicts) and requirement scope (build vs. test vs. runtime) as completely orthogonal. Currently there's no such thing as build

Re: [Module::Build] Re: Test::META

2005-03-30 Thread Michael G Schwern
On Wed, Mar 30, 2005 at 06:12:37AM -0500, Randy W. Sims wrote: > Both. We could fail by default, but allow an option to force it to > ignore missing or conflicting dependencies: Duh. Why didn't I think of that? Of course!

Re: [Module::Build] Re: Test::META

2005-03-30 Thread Randy W. Sims
Clayton, Nik wrote: On Tue, Mar 29, 2005 at 08:33:48PM -0500, Randy W. Sims wrote: A quickie sample implementation to add more meat. I didn't apply yet mainly because I'm wondering if we shouldn't bail and do a complete roll-back (eg. don't generate a Build script) if there are any failed requir

RE: [Module::Build] Re: Test::META

2005-03-30 Thread Clayton, Nik
> On Tue, Mar 29, 2005 at 08:33:48PM -0500, Randy W. Sims wrote: > > A quickie sample implementation to add more meat. I didn't apply yet > > mainly because I'm wondering if we shouldn't bail and do a complete > > roll-back (eg. don't generate a Build script) if there are any failed > > require

Re: [Module::Build] Re: Test::META

2005-03-29 Thread Randy W. Sims
Michael G Schwern wrote: On Tue, Mar 29, 2005 at 08:33:48PM -0500, Randy W. Sims wrote: A quickie sample implementation to add more meat. I didn't apply yet mainly because I'm wondering if we shouldn't bail and do a complete roll-back (eg. don't generate a Build script) if there are any failed r

Re: [Module::Build] Re: Test::META

2005-03-29 Thread Michael G Schwern
On Tue, Mar 29, 2005 at 08:33:48PM -0500, Randy W. Sims wrote: > A quickie sample implementation to add more meat. I didn't apply yet > mainly because I'm wondering if we shouldn't bail and do a complete > roll-back (eg. don't generate a Build script) if there are any failed > requirements. Or s

Re: [Module::Build] Re: Test::META

2005-03-29 Thread Randy W. Sims
Michael G Schwern wrote: On Tue, Mar 29, 2005 at 04:43:30PM -0600, Ken Williams wrote: I think there's one really good argument in favor of splitting it out and one really good argument against. In favor: if we knew the subset of build_requires that were actually needed for testing, then it woul

Re: [Module::Build] Re: Test::META

2005-03-29 Thread Michael G Schwern
On Tue, Mar 29, 2005 at 04:43:30PM -0600, Ken Williams wrote: > I think there's one really good argument in favor of splitting it out > and one really good argument against. > > In favor: if we knew the subset of build_requires that were actually > needed for testing, then it would be easier for

Re: [Module::Build] Re: Test::META

2005-03-29 Thread Ken Williams
On Mar 28, 2005, at 6:21 PM, Randy W. Sims wrote: I think someone had proposed a year or two ago that there should be a test_requires options and I argued against it. Now, I think maybe it was a good idea; especially, since the number of extra testing modules being used have increased a lot over

Re: [Module::Build] Re: Test::META

2005-03-29 Thread David Wheeler
On Mar 28, 2005, at 4:21 PM, Randy W. Sims wrote: I think someone had proposed a year or two ago that there should be a test_requires options and I argued against it. Now, I think maybe it was a good idea; especially, since the number of extra testing modules being used have increased a lot over