On Mon, Sep 22, 2008 at 3:00 PM, David Golden [EMAIL PROTECTED] wrote:
Problem 1: race condition between unarchiving and execution if
Makefile.PL or Build.PL is world writable (ditto test files as well)
(a) Have CPAN and CPANPLUS refuse to run 'perl *.PL' if the PL in
question is world
On Mon, Sep 22, 2008 at 5:23 PM, Eric Wilhelm
[EMAIL PROTECTED] wrote:
Would that tracks-covering chmod not require *ownership* of the file?
According to the man page for chmod(1), yes, but on Win32 doesn't a
world-writable file mean it's world-replaceable too?
In any case, I was also trying
On Oct 19, 2007, at 6:00 AM, David Cantrell wrote:
Dave Golden and I have been hacking on Devel::CheckLib, which
should be
on a CPAN mirror near you soon. It's similar to Devel::CheckOS, in
that
it will let module authors specify dependencies which aren't just
other
perl modules - if
On Sep 11, 2006, at 7:08 PM, Randy W. Sims wrote:
Ovid wrote:
Last week I was at a testing conference with Acme and he came up
with the idea of installing tests. He looked into hacking
Module::Build and ExtUtils::MakeMaker. He also considered hacking
CPAN.pm and CPANPLUS.pm. While I
On Jul 21, 2006, at 12:58 AM, Adam Kennedy wrote:
It's at this point I make very quiet noises about YAML::Tiny, and
how it only supports ordinary data, so things like objects and
circulars and other crazy things can't happen.
It's not done yet, but the basics all should work.
You might
On Jul 20, 2006, at 9:07 PM, David Golden wrote:
$node is a YAML::Node and the EXISTS function only checks for
things stored in the NODE property, not the HASH property. I'm not
sure exactly what those two are supposed to be representing, but
the point is that the exists
On Jul 5, 2006, at 7:47 PM, David Golden wrote:
Some potential options:
(a) Add directory as a synonym to the spec and add dir as
something that CPAN sites recognize.
(b) Change the spec to directory -- if CPAN sites are the only
real user of META.yml no_index, then the pain should be
On Feb 24, 2006, at 11:42 PM, Tyler MacDonald wrote:
Adam Kennedy [EMAIL PROTECTED] wrote:
So while we are on the subject of META.yml, I think the
dynamic_config
approach is horrible, because it defaults to an efficient error
case and
relies on the author to fix the error, rather than
On Apr 8, 2005, at 12:32 PM, Michael G Schwern wrote:
die NA: $reason;
Since, at the moment, we're having trouble putting together a system to
cover the possible reasons for an NA report let the module author
figure it
out. Its simple and minimal.
I like it.
-Ken
On Apr 6, 2005, at 7:13 AM, Robert Rothenberg wrote:
Is there a way tests to determine that a module cannot be installed on
a platform so that CPANPLUS or CPAN::YACSmoke can issue an NA (Not
Applicable) report?
CPANPLUS relies on module names (e.g. Solaris:: or Win32::) but
that is not always
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 and
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 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'
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
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
On Feb 23, 2005, at 6:08 PM, Michael G Schwern wrote:
For any brave Phalanx folks who wish to target MakeMaker I can point
you at
some critically deficient areas of its testing.
1) XS. There is absolutely no testing of XS code. The primary
problem is
determining if the user has a working
Some thoughts:
1) In order to be convenient for the code author, he/she should be able
to poll for available clients before submitting a job. My inclination
would be to make this a simple inetd on the client, rather than any
persistent connection between client server. I think if there were
On Tuesday, September 3, 2002, at 08:56 AM, Michael G Schwern wrote:
On Mon, Sep 02, 2002 at 08:13:06AM +0100, Nick Ing-Simmons wrote:
I understand all that. My point was that while test itself may care
where it is run, blib.pm does not mind as much. Also blib.pm's job
is to make running an
On Tuesday, September 3, 2002, at 03:10 PM, Michael G Schwern wrote:
On Tue, Sep 03, 2002 at 11:26:01AM +1000, Ken Williams wrote:
Thus is you need to be in t this might suit
cd t; perl -Mblib=lib foo/bar.t
I'd be happier if that 'cd t;' happened inside blib.pm as 'chdir t'.
It already
On Tuesday, September 3, 2002, at 08:56 AM, Michael G Schwern wrote:
On Mon, Sep 02, 2002 at 08:13:06AM +0100, Nick Ing-Simmons wrote:
I understand all that. My point was that while test itself may care
where it is run, blib.pm does not mind as much. Also blib.pm's job
is to make running an
On Thursday, August 29, 2002, at 06:25 PM, Michael G Schwern wrote:
On Thu, Aug 29, 2002 at 06:23:26PM +1000, Ken Williams wrote:
I admit that I was a little surprised to see 'lib' stuff here
and not 'blib' stuff. Don't blibs get created when building
modules in the core?
Everything
On Thursday, August 29, 2002, at 05:53 PM, Nicholas Clark wrote:
For information, my example was from the top of t/integer.t in Storable
It looks like the same bit of code was cargo-cult cut pasted (er, by
me I think) from the other Storable tests (such as freeze.t) where they
have to
On Thursday, August 29, 2002, at 06:25 PM, Michael G Schwern wrote:
On Thu, Aug 29, 2002 at 06:23:26PM +1000, Ken Williams wrote:
I admit that I was a little surprised to see 'lib' stuff here
and not 'blib' stuff. Don't blibs get created when building
modules in the core?
Everything
On Thursday, August 29, 2002, at 05:53 PM, Nicholas Clark wrote:
For information, my example was from the top of t/integer.t in Storable
It looks like the same bit of code was cargo-cult cut pasted (er, by
me I think) from the other Storable tests (such as freeze.t) where they
have to
On Thursday, August 29, 2002, at 05:29 PM, Michael G Schwern wrote:
There's already the beginnings of something like this in
t/TestInit.pm, but
it wasn't updated for the PERL_CORE trick. Nor do I know if it can be
entirely trusted.
Also, Nick's example is a little odd. You usually don't
On Thursday, August 29, 2002, at 05:29 PM, Michael G Schwern wrote:
There's already the beginnings of something like this in
t/TestInit.pm, but
it wasn't updated for the PERL_CORE trick. Nor do I know if it can be
entirely trusted.
Also, Nick's example is a little odd. You usually don't
.
This includes modules like GD.pm (requires several external libraries)
or HTML::Mason (has interactive 'make test').
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math
27 matches
Mail list logo
