> > no_index/dir 13
> > no_index/directory 1397
> > private/directory40
> As for "dir", I'm three of the 13,
I'm another three of the 13, and I'll switch to 'directory' as of the
next upload.
-- Johan
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Has a README... check
Bonus points if it differs from the stub, and additional bonus points
if it really describes briefly what the product is.
Rationale: When browsing READMEs they are often meaningless.
> Declares a $VERSION...
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
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
Yitzchak Scott-Thoennes <[EMAIL PROTECTED]> writes:
> main() unless caller;
I use this (and teach it in my trainings) as an easy way to insert
some basic verification tests in modules. At the end of the module:
unless ( caller ) {
package main;
... insert test code ...
}
-- Johan
[Quoting Michael G Schwern, on March 6 2005, 10:32, in "Re: testing non-modu"]
> Or if you want to be super portable you can do this:
>
> use Test::Output;
> local @ARGV = qw(some args);
> stdout_is( sub { do "bin/myprogram" }, 'wibble' );
>
> Which has the nice side benefit of
Andy Lester <[EMAIL PROTECTED]> writes:
http://www.petdance.com/random/tap.html
> Everyone: I still need more comments. Pete Krawczyk's the only one to
> provide complaints yet.
@ Test number
1..6
not ok
ok
not ok
ok
ok
will generate
FAILED tests 1, 3, 6
Andy Lester <[EMAIL PROTECTED]> writes:
>> Is it ok for a CPAN module to use other modules from CPAN only for the
>> test scripts (e.g. "Text::Diff")?
>
> Yes. See http://phalanx.kwiki.org/index.cgi?StandardDotTFiles for
> examples of .t files that only run if a certain module is installed.
Hmm.
Leon Brocard <[EMAIL PROTECTED]> writes:
> This is what you get when you set Module::Packaged against the Phalanx
> 100. So right now FreeBSD packages the most of Phalanx, and it's kinda
> interesting to see the version numbers.
>
> There might be bugs,
Definitely. I'm quite sure Getopt::Long is
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Giving read() semantics completely unrelated to reading a filehandle would
> be a bad choice of syntax.
I wonder what the people who implemented the GNU/Linux "procfs" think
about this.
-- Johan
Michael G Schwern <[EMAIL PROTECTED]> writes:
> And if you're not using a CPAN shell every module install is going
> to be a chore anyway.
Tchk. I think it's quite nice and powerful to be able to download an
arbitrary module's .tar.gz and get it going with the simple "perl
Makefile.PL; make all
Michael G Schwern <[EMAIL PROTECTED]> writes:
> It's probably easier to just make it a normal prerequisite.
My hesitation in doing this is that the module does not need Test::*
for its operation, just for the IVP.
But I tend to agree that making any special provisions for this
purpose is proba
Janek Schleicher <[EMAIL PROTECTED]> writes:
> A good solution from my point of view would be,
> if you could use Makefile.PL to do this job,
> perhaps similar to
> 'PREREQ_PM' => { ... }
> a
> 'PREREQ_TEST_PM' => { ... }
> statement,
> warning the user that the test can't be done without a speci
chromatic <[EMAIL PROTECTED]> writes:
> On Fri, 26 Jul 2002 13:19:51 -0700, Johan Vromans wrote:
> This idea appeals to me, but I have thought of two drawbacks. The first is
> minor, and it's that I don't think Test::Builder should have special logic for
> insta
Folks,
One of the problems I have with using Test::Builder is that I want to
distribute packages to systems that do not (necessarily) have a decent
version of Test::* installed. Now it is easy to include a copy of a
suitable version of Test::Builder with the package (provided it is not
too big).
> # parse the command-line
> -my $result = GetOptions( qw(
> +my $result = GetOptions( map {
> + my $key = $_;
> + $key =~ s/\W.+$//;
> + $key => \$Options{$_};
> +} qw(
> help
> podpath=s
> podroot=s
I'm not sure what you are trying to a
[Quoting Kirrily Robert, on October 9 2001, 23:56, in "Re: Test::Harness in"]
> I think he's trying to say that Perl (i.e. the "Perl community") should
> define these things so that different packagers (Debian, Red Hat,
> whoever) can have somewhat-consistent packages.
Exactly. Sorry for my uncle
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Debian has the beginnings of that. perl-base is the minimum necessary
> to have a useful Perl, basically a binary, the perl man page, and a
> handful of critical modules ...
Wouldn't it be a good idea to try to define packages like these, so
that
[Quoting Michael G Schwern, on October 8 2001, 14:46, in "Re: Test::Harness in"]
> On Mon, Oct 08, 2001 at 10:20:20AM +0200, Johan Vromans wrote:
> > But I agree with everyone who says there should be a better, more
> > generic solution.
>
> Debian. ;)
Actually,
Michael G Schwern <[EMAIL PROTECTED]> writes:
> It means both packages lay claim to /usr/lib/perl5/5.6.0/Test/Harness.pm and
> /usr/share/man/man3/Test::Harness.3pm.gz. Can't happen
Oh yes, it does. Frequently.
I ran into the same problem when I tried to make installable packages
for Getopt::Lo
Michael G Schwern <[EMAIL PROTECTED]> writes:
> I'd like to propose two simple critereon for all future module
> additions to the core:
> [two simple critereon follow]
Personally, I'd like to impose these to any CPAN submission
whatsoever...
For modules to be part of the core the requirements c
As an active non-smoker, I'd appreciate a different name.
-- Johan
Tom Christiansen <[EMAIL PROTECTED]> writes:
> No, I would argue that undef() be changed to uninitialize().
> This is infinitely better for many, many reasons.
>
> 1) Because it's now an action verb. the English semantics of
>the word change will encourage the correct
>
>
23 matches
Mail list logo
