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
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
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
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
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
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.
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
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
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!
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
> 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
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
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
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
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
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
On Tue, Mar 29, 2005 at 09:04:54AM -0500, Christopher H. Laco wrote:
> I was. But at some level, I'm not.
> If after changing one dist to use M::B I have more issues than I started
> with [which was just checking the syntax of my manually edited
> META.yml], then there's no reason to move all of
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
Michael G Schwern wrote:
[snip]
Sticking with ExtUtils::MakeMaker. :-)
[But where's the fun in that.]
I know you're joking, but you've flipped my rant switch.
I was. But at some level, I'm not.
If after changing one dist to use M::B I have more issues than I started
with [which was just checking
On Mon, Mar 28, 2005 at 08:35:34PM -0800, Michael G Schwern wrote:
> > Whether things that are required for *testing* belong in
> > build_requires really depends on whether you view testing as an
> > integral part of the build process. This is something that is likely
> > to depend on the *builder
On Mon, Mar 28, 2005 at 06:59:59PM -0800, Yitzchak Scott-Thoennes wrote:
> > There is no build_requires or recommends equivalent in MakeMaker, nor will
> > there be,
>
> Too bad. Seems to me it would make sense to have MakeMaker support
> adding the tags to META.yml.
Yes, it would make perfect
On Mon, Mar 28, 2005 at 03:10:52PM -0800, Michael G Schwern wrote:
> On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote:
> > That's another gripe of mine about M::B and create_makefile_pl.
> > It puts the requires AND build_requires in the PREREQ_PM in the
> > Makefile.PL, which I
Michael G Schwern wrote:
On Mon, Mar 28, 2005 at 07:52:22PM -0500, Christopher H. Laco wrote:
Michael G Schwern wrote:
Until such time as there are test_* flags, one should take a pragmatic
view.
And that view is "what is going to cause the least amount of hassle for
those who want to inst
On Mon, Mar 28, 2005 at 07:52:22PM -0500, Christopher H. Laco wrote:
> Michael G Schwern wrote:
> >Until such time as there are test_* flags, one should take a pragmatic
> >view.
> >And that view is "what is going to cause the least amount of hassle for
> >those who want to install my module" beca
Michael G Schwern wrote:
Until such time as there are test_* flags, one should take a pragmatic view.
And that view is "what is going to cause the least amount of hassle for
those who want to install my module" because they don't know nor care about
the internal mechanics.
[snip]
Sticking with Ex
On Mon, Mar 28, 2005 at 06:20:32PM -0500, Christopher H. Laco wrote:
> >Its better than just dropping it and having the build fail.
>
> That's a matter of opinion; one I think should be left up to the person
> makeing Build.PL.
That sort of dubious flexibility is well out of the scope of
Module
Christopher H. Laco wrote:
Michael G Schwern wrote:
On Sun, Mar 27, 2005 at 08:32:59PM -0500, Christopher H. Laco wrote:
Along the lines of converting to Module::Build...it went well until I
started doing tests...things that worked now break, probably do to
how they're now run...
t\xsp.
Christopher H. Laco wrote:
Michael G Schwern wrote:
On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote:
That's another gripe of mine about M::B and create_makefile_pl.
It puts the requires AND build_requires in the PREREQ_PM in the
Makefile.PL, which I won't want; nor do I think i
Michael G Schwern wrote:
On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote:
That's another gripe of mine about M::B and create_makefile_pl.
It puts the requires AND build_requires in the PREREQ_PM in the
Makefile.PL, which I won't want; nor do I think it right for everyone.
Ther
On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote:
> That's another gripe of mine about M::B and create_makefile_pl.
> It puts the requires AND build_requires in the PREREQ_PM in the
> Makefile.PL, which I won't want; nor do I think it right for everyone.
There is no build_requi
Michael G Schwern wrote:
There is a create_makefile_pl option (see Module::Build::Compat) which
does a fair job of creating a Makefile.PL functionally equivalent to
your Build.PL. It comes in various flavors from passthrough (where it
writes a Makefile which simply calls Module::Build functions) t
Michael G Schwern <[EMAIL PROTECTED]> writes:
> There is a create_makefile_pl option (see Module::Build::Compat) which
> does a fair job of creating a Makefile.PL functionally equivalent to
> your Build.PL.
I'll definitely give it a try. Thanks.
-- Johan
On Mon, Mar 28, 2005 at 01:04:45PM +0200, Johan Vromans wrote:
> Michael G Schwern <[EMAIL PROTECTED]> writes:
>
> > Switch to Module::Build anyway.
>
> I would love to.
> But the last time I submitted a M::B-only module I was 'kindly urged'
> to provide a Makefile.PL as well, factually defeating
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Switch to Module::Build anyway.
I would love to.
But the last time I submitted a M::B-only module I was 'kindly urged'
to provide a Makefile.PL as well, factually defeating the advantages
of using M::B.
Maintaining both a Build.PL and a Makefile.P
On Sun, Mar 27, 2005 at 09:20:25PM -0500, Christopher H. Laco wrote:
> My bet is that the shebang -w in my *.t files are kicking in where they
> weren't before; pointing to a difference in how they're invoked between
> the two envorinments.
No, that's a Test::Harness thing and both MM and MB wil
Michael G Schwern wrote:
On Sun, Mar 27, 2005 at 08:32:59PM -0500, Christopher H. Laco wrote:
Along the lines of converting to Module::Build...it went well until I
started doing tests...things that worked now break, probably do to how
they're now run...
t\xsp.Use of uninitialized va
On Sun, Mar 27, 2005 at 08:32:59PM -0500, Christopher H. Laco wrote:
> Along the lines of converting to Module::Build...it went well until I
> started doing tests...things that worked now break, probably do to how
> they're now run...
>
> t\xsp.Use of uninitialized value in translit
Randy W. Sims wrote:
There is my unpublished CPAN::Metadata at:
svn co http://svn.versiondude.net/randys/CPAN-Metadata/trunk/ CPAN-Metadata
It reads, writes, and validates metadata according to the spec. It still
needs a bit of work, and updates to the actual spec need to be
formalized before it
mistakes every time I upload a new version of
a module.
More than once now I've fubared my META.yml just enough that
CPAN/Kobesearch won't touch it. I'd like to remedy that problem with a
simple Test::META to check my syntax every time I make changes.
There is my unpublished
On Sat, Mar 26, 2005 at 10:14:59PM -0500, Christopher H. Laco wrote:
> Reading...reading...reading...reading..done.
> Still doesn't help with the no_index problem, but it looks interesting.
I saw something about no_index on the module-build-general list just
recently so maybe next
Christopher H. Laco wrote:
Michael G Schwern wrote:
On Sat, Mar 26, 2005 at 07:52:45PM -0500, Christopher H. Laco wrote:
Well, unless I missed something [likely], to add things after the
module is created or updated. Changing requirements, recommends, and
build_requires for starters. Sometimes no
Michael G Schwern wrote:
On Sat, Mar 26, 2005 at 07:52:45PM -0500, Christopher H. Laco wrote:
Well, unless I missed something [likely], to add things after the module
is created or updated. Changing requirements, recommends, and
build_requires for starters. Sometimes no_index when new modules are
On Sat, Mar 26, 2005 at 07:52:45PM -0500, Christopher H. Laco wrote:
> Well, unless I missed something [likely], to add things after the module
> is created or updated. Changing requirements, recommends, and
> build_requires for starters. Sometimes no_index when new modules are
> added to dists.
Andy Lester wrote:
On Mar 26, 2005, at 6:29 PM, Christopher H. Laco wrote:
Is anyone aware of any existing code (aside from YAML) for grocking
META.yml?
Why are you changing it manually?
Well, unless I missed something [likely], to add things after the module
is created or updated. Changing requ
On Mar 26, 2005, at 6:29 PM, Christopher H. Laco wrote:
Is anyone aware of any existing code (aside from YAML) for grocking
META.yml?
Why are you changing it manually?
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
d a new version of
a module.
More than once now I've fubared my META.yml just enough that
CPAN/Kobesearch won't touch it. I'd like to remedy that problem with a
simple Test::META to check my syntax every time I make changes.
-=Chris
smime.p7s
Description: S/MIME Cryptographic Signature
46 matches
Mail list logo
