I should mention that in it's currently form it's fairly enterprisey (a
bit of dependency bloat, and lacking in tutorial'esk stuff).
I'll try to post an alpha shortly, and if anyone would like to help
finish it off (adding back some legacy features, playing with it to
provide feedback) I'd be a
Test::Inline 2.00_01 has been uploaded to CPAN.
Rough Status
- API documentation should be quite thorough
- User/Tutorial stuff is insufficient
- Adding files/dir is not as easy as it should be
- No support for =for
- As a standalone module, it's a bit too class-centric, needs to be a
bit more fil
You've seen "ab" right? Was written for benchmarking Apache?
OK, you can only throw the one page at it I think, but I find it very
useful for finding out the basic page overhead and stability under
parellel load.
Adam K
CÃdric Bouvier wrote:
Hello there.
I once had to organize the stress testing
Hear hear. I'd rather see better-kwalitee kwalitee tests :)
Once the number and value of the kwalitee tests gets higher, it should
be expected that people are almost never going to score perfect.
Adam K
Johan Vromans wrote:
Michael G Schwern <[EMAIL PROTECTED]> writes:
Has a README... check
B
Finally, the scoreboard does have a purpose. Part of the original idea of
CPANTS was to provide an automated checklist for a good distribution.
Has a README... check
Declares a $VERSION... check
Well behaved tarball... no
And as far as I can tell, got sidetracked a
David Cantrell wrote:
Thomas Klausner wrote:
I cannot check POD coverage because Pod::Coverage executes the code.
No it doesn't. That said, if you don't want to run the code you're
testing, you are, errm, limiting yourself rather badly.
Do YOU want to run all of CPAN?
I certainly don't.
Bulk te
Adding a kwalitee check for a test that runs Devel::Cover by default
might on the surface appear to meet this goal, but I hope people
recognize it as a bad idea.
Why, then, is suggesting that people ship tests for POD errors and
coverage a good idea?
Although I've now added the automated inclusion
David Wheeler wrote:
On Apr 7, 2005, at 11:32 AM, Christopher H. Laco wrote:
OK, now whos gonna build JPANTS? :-)
JSPANTS, you mean? I think we need a CJSPAN, first. Alias?
Yes well... I'm getting there slowly.
JavaScript::Librarian + Algorithm::Dependency + YAML ought to be enough
to get some b
* Decide where to send test output, and where to allow other output to
be sent. Test::Builder clones STDERR and STDOUT for this purpose. We'll
probably have to do it by overriding C, but it'd be
good to allow users to define alternate outputs (tests may not always
run in a browser, eh?). Maybe
Christopher H. Laco wrote:
Tony Bowden wrote:
On Thu, Apr 07, 2005 at 12:32:31PM -0400, Christopher H. Laco wrote:
CPANTS can't check that for me, as I don't ship those tests.
They're part of my development environment, not part of my release
tree.
That is true. But if you don't ship them, how do
Michael Graham wrote:
Another good reason to ship all of your development tests with code is
that it makes it easer for users to submit patches with tests. Or to
fork your code and retain all your development tools and methods.
Perl::MinimumVersion, which doesn't exist yet, could check that the
v
David Wheeler wrote:
On Apr 16, 2005, at 3:00 PM, Adam Kennedy wrote:
It's going to totally depend on what you want to wrap around it...
Do you want the human interacty mode? Or the machine county mode.
"machine county mode"? Just that, I think.
Forget the document object for a
What I'm moving towards is what SVK does. It has an SVK::Version module
which simply defines $SVK::VERSION. Then in other modules you can write:
use SVK::Version; our $VERSION = $SVK::VERSION;
That way it will be picked up by most $VERSION scanners.
See my post further up about syncron
> I've yet to read anything /really/ convincing for either side -
so I'd do whatever you're comfortable with myself.
In my case I tend to use synchronised version numbers. For big APIs (20+
classes) I often use Class::Autouse to recursively load them.
If two subsequent versions of the dist chang
David Cantrell wrote:
Adrian Howard wrote:
On 18 Apr 2005, at 17:03, David Cantrell wrote:
Number::Phone::UK::Data - no version, this is where the .0004 comes from
though. It has no version number because the
entire file is generated from a *real
Have you had a look at CGI::Capture?
That may do some things you can abuse to get what you want.
Adam K
Vsevolod Ilyushchenko wrote:
Hi,
I'd like to suggest a module that I came up with to test CGI file
uploading logic. I have not found anything else like it.
If anyone has any thoughts on
Just a quick heads up and request for comments on a testing module I'm
putting together.
Test::Object
See search.cpan.org once the initial POD-only upload is done, but in
short I want a way to be able to define tests or groups of tests that
ANY object of a particular class should pass, and th
Hiya folks
Well after 2 years and 1 month, it's finally as "done" as it's going to be.
I hereby announce the release of Test::Inline 2.
It would have happened sooner, but I made the foolish assumption that
Test::Inline 1 actually used the Test::Inline namespace.
After discovering that pod2te
Michael G Schwern wrote:
I'm going through some work to restore Test::More and Test::Harness to work
on 5.4.5, minor stuff really, and I'm wondering if its worth the trouble.
Has anyone seen 5.004_xx in the wild? And if so, were people actively
developing using it or was it just there to run so
I've just been through the should-I-shouldn't-I-support-5.4 with my
(painfully slow) rewrite of Compress::Zlib. In the end I included limited
support for 5.004 because I could, plus I have no feel for how much pain I
would cause folk if I didn't.
If anyone cares about this enough to do somethin
As someone whose production code is currently required to run under
5.5.3, I'm very grateful to module authors whose code still runs under
that version at least. A number of modules which don't run under 5.5.3
do with simple changes, primarily changing "our" to "use vars" and
getting rid of x.y.z
Mark Stosberg wrote:
If you haven't see AnnoCPAN, it's a new way to share comments on Perl
POD:
But not with the actual AUTHOR of the module apparently. From what I can
tell, this does nothing at all to help the author of the modules.
There's no way to get a listing of the annotations for a
Mark Stosberg wrote:
If you haven't see AnnoCPAN, it's a new way to share comments on Perl
POD:
Example:
http://www.annocpan.org/dist/Net-ICal-0.15/lib/Net/ICal.pm
I have an idea about taking it a step further-- making it easier to
close the loop with the author to integrate updates.
CPAN d
PS. An AnnoCPAN tip: Notice that if you are an author, you can subscribe
to all comments on your modules:
http://www.annocpan.org/~MARKSTOS/recent.rss
I don't _want_ to subscribe to my feed. RSS would be just another
distration in my life.
What I'd just like, every 3 months or so when I've go
Adrian Howard wrote:
On 8 Jul 2005, at 20:08, Adam Kennedy wrote:
[snip]
There's no way to get a listing of the annotations for a given author
id, or even for a given dist. So I'm reduced to manually looking
through a thousand odd web pages to find potential changes or
impro
Adrian Howard wrote:
On 8 Jul 2005, at 20:08, Adam Kennedy wrote:
[snip]
There's no way to get a listing of the annotations for a given author
id, or even for a given dist. So I'm reduced to manually looking
through a thousand odd web pages to find potential changes or
impro
Nik Clayton wrote:
Having been a little more prolific on the module front recently I'm
interesting in making sure that my own modules pass the kwalitee tests.
Preferably before I put them on CPAN.
But poking through qa.perl.org I can't find anywhere that these tests
are actually rigorously d
Note: The last kwalitee test, the one related to Devel::Cover, is
considered dangerous by a non-trivial percentage of the community,
and there's been a lot of debate on whether it should be removed.
Sorry, I should have said Pod::Test::Coverage.
Regardless, it executes code. I wonder how it de
Ricardo SIGNES wrote:
* Adam Kennedy <[EMAIL PROTECTED]> [2005-07-11T10:10:31]
Note: The last kwalitee test, the one related to Devel::Cover, is
considered dangerous by a non-trivial percentage of the community,
and there's been a lot of debate on whether it should be removed.
Michael G Schwern wrote:
On Tue, Jul 19, 2005 at 10:49:12PM -0400, James E Keenan wrote:
The inference I drew was that the four false positives I received for
v0.35 came from automated testing in an environment where IO::Capture
was already installed, so that the test script did not need to fi
ious...
Adam K
Michael G Schwern wrote:
On Wed, Jul 20, 2005 at 05:21:19PM +1000, Adam Kennedy wrote:
The image-based platforms would be able to implement a fresh
from-the-base-install install of each module. This would also greatly
help to focus attention on modules that many many others re
Robert wrote:
I am creating my first module (finally) and I was told a while ago to use
Module::Starter. Which I did. I am fine there. When I look at the code
generated I see that all the POD stuff is inline while I prefer to see POD
stuff at the end. Is the inline POD the current preferred way?
Sébastien Aperghis-Tramoni wrote:
Adam Kennedy wrote:
has_perl_dependency:
In the META.yml (assuming it exists) there is a dependency on the
version of perl required to install the dist.
Problem is that the version said to be required is often bogus. For example,
the distributions created
e::Install;
name ( 'Class-Autouse' );
abstract ( 'Run-time class loading on first method call' );
author( 'Adam Kennedy<[EMAIL PROTECTED]>' );
version_from ( 'lib/Class/Autouse.pm' );
license
The first demo of this I'm
hoping to do is a use of Perl::MinimumVersion to find cases where a
module is listed as working with (for example) Perl 5.005, but the
module syntax shows that it needs 5.006. (and thus the version
dependency is wrong).
I later plan to expand this to include cases w
Apart from a user wanting to know which version of perl a module
works with, it's a general "quality" (not kwalitee;-) principle to
first specify, then test that the specification is met. So I would
say that specifying which versions of perl your module is meant to
work with should be done before
Andy Lester wrote:
Why are we worrying about these automated kwalitee tests? What will
happen once we find that DBIx::Wango has only passed 7 of these 23 items
on the checklist?
I thought the same thing, until kwalitee turned competative. Now we have
a situation in which a large number
David Cantrell wrote:
Tels wrote:
If I were to run CPANTS, I would drop that module like a hot potato at
a summer campfire.
Oh, and reduce everyone's K rating involved in the little prank by
one :)
I thought the whole point of CPANTS was to be useful to authors, not
useful to the CPANTS
Chromatic wrote:
On Fri, 2005-09-09 at 22:28 +0100, Nicholas Clark wrote:
For search results quite the opposite. I'd really like if if the default
way people got search results back for CPAN modules at least attempted
to order at some level based on citations. (ie number of pre-requisites)
I've found that by using Module::Install, I can often just bundle those
small miscellaneous testing modules, and occasionally a few of their
dependencies.
And for something simple as "the tests don't generate warnings", I would
think "module has excessive dependencies" is a bug in Test::Deep,
If you get hit by a truck and someone updates Test::Moose to take
care of a bug, who will update your bundled version?
Simple. Because I don't bundle it by hand, Module::Install does it.
Bundling things by hand would be WAY too much work.
The next time someone else rolls the build, it autom
Chromatic wrote:
On Mon, 2005-09-12 at 09:36 +1000, Adam Kennedy wrote:
If you do realize, but it takes you 3 days to update once mainline
was fixed, and it takes mainline 3 days to update once Joe Random's
patch was submitted, why should new users from these 3 days get a
buggy, out
Andy Lester wrote:
On Sep 11, 2005, at 7:25 PM, chromatic wrote:
I don't feel as confident as you do that if the tests all passed on your
machine that they'll automatically pass everywhere.
THIS is my biggest point. It's not about the quality of the code so
much as making sure the code
But if someone
else helps you install the machine, then you don't actually need the level,
if they bring theirs and use it for the install.
I think that the build_requires/test_requires distinction *is* important, if
it can be made, as it eases the lives of anyone wishing to package up
modules,
Rather than do any additional exploding, I'd like to propose the
additional kwalitee test "has_changes". I've noticed that a percentage
(5-10%) of dists don't have a changes file, so it can be hard to know
whether it's worth upgrading, or more importantly which version to add
dependencies for.
H.Merijn Brand wrote:
On Thu, 15 Sep 2005 11:52:00 +1000, Adam Kennedy <[EMAIL PROTECTED]> wrote:
Rather than do any additional exploding, I'd like to propose the
additional kwalitee test "has_changes". I've noticed that a percentage
(5-10%) of dists don't ha
It's been a while since I released Test::Inline 2. And as far as I was
aware, everything was just fine.
Except that it wasn't... apparently a whole bunch of people and some
quite significant projects have had issues with the fact that the new
version doesn't have a pod2test script (that they w
ope of CPANTS is bound to shake out bugs in PPI, which
will make Adam Kennedy happy. (FSDO happy).
David
Been there done that. Go check out PPI::Tinderbox. It was... well... fun
(FSDO fun) :)
But I'm always happy to get more bug reports.
Adam K
Michael Graham wrote:
As I was downloading the newest version of Devel::Cover this morning, I
pondered on the concept of 1 Kwalitee point for coverage >= 80%, and
another for 100%, and how absolutely impossible it would be to set out
to establish these points for all the modules on CPAN. But it w
It's impossible.
Quite. I believe the only way is for the author to do the Devel::Cover
dance and forward the results. It also distributes the workload out to
where it should be done.
Since it's an optional step that has no direct bearing on the
functionality of the module, it's a sign tha
Paul Johnson wrote:
On Fri, Sep 23, 2005 at 12:06:43PM +0200, Thomas Klausner wrote:
Hi!
On Fri, Sep 23, 2005 at 12:54:42PM +1000, Adam Kennedy wrote:
Collecting any sort of coverage data is a complete bitch. Let me just
say right now that doing it across _all_ of CPAN is flat out
Michael G Schwern wrote:
On Fri, Sep 23, 2005 at 05:38:32PM +0200, Tels wrote:
If you have any ideas how to make this even more usefull, please speak
now. I will have limited email reading/writing capabilities the next two
weeks, but I *will* respond to all emails/critics/praises, even though i
Unless someone wants to start helping implement this right now, I'd ask
that you not spend too much time on anything that relates to
Kwalitee/PPI integration (which includes Perl::Critic).
There's a couple of steps that have to be taken in order to make this
happen, and I'm working through the
The new version of Test::More from Sep 23rd improved the STDERR output
on test failure. Unfortunately, this has accidentally broken
Test::Builder::Tester's test_fail function. (and maybe other
test-testing modules)
http://rt.cpan.org/NoAuth/Bug.html?id=14936
T:B:Tester is used by about 26 oth
Some more test failures confirmations...
Test::Exception is uninstallable.
Test::SubCalls is uninstallable.
Test::Pod is uninstallable.
Test::Warn is uninstallable.
test_fail() which is the problem in TB::Tester was really only a
convenience function for test_diag( Failed at ... ).
Pretty
* Rolling back the change is a pain in my ass.
BTW, this shouldn't be true.
Just grab the previous stable tarball, unroll it, change the version to
a higher one, and release. If it's a bitch to backout that one path,
backout the entire stable release to the previous one.
It's 5 lines of cod
AFAIK there is only one module of consequence which does screen scraping
on Test::More and that's Test::Builder::Tester (Test::Warn, it turns out,
fails because of Test::Builder::Tester). Fix that, upload a new version
and the problem goes away.
Which is not true at all. Test::More gets upgra
Just grab the previous stable tarball, unroll it, change the version to
a higher one, and release. If it's a bitch to backout that one path,
backout the entire stable release to the previous one.
Did you see the number of bug fixes between 0.60 and 0.61? No, I'm not
rolling back the entire re
I'm disinclined to back this change out. See the bug for reasoning.
http://rt.cpan.org/NoAuth/Bug.html?id=14936
To sum up:
* There was ample warning.
* You shouldn't be relying on screen scraping.
* The fix to Test::Builder::Tester is trivial.
* Rolling back the change is a pain in my ass.
The
AmethystSHEVEK
Apache-ACEProxy MIYAGAWA
Apache-DoCoMoProxy KOBAYASI
Apache-Gallery LEGART
Apache-No404Proxy MIYAGAWA
[...the long list of modules continues...]
This list came from CPANTS, right? I think there's something screwy
with the way it's following dependencies.
* has_pod_index: The POD contains at least one X<> keyword that helps
POD indexers. Whether only one is usefull is open for debate, because
at least the license (X), your CPAN ID under authors (x),
and some generic keyword what your module (X) is about can
probably added even for the most minima
Doesn't makemaker only like you if you have a single .pm file just in
the root directory?
And otherwise you have to have your lib files actually under lib?
lib/Tree/Splay.pm
lib/Tree/Splay/Node.pm
lib/Tree/Splay/IntRange.pm
t/01_basics.t
t/02_compat.t
Makefile.PL
MANIFEST
-
us
My main comment would be that it can be very easy to get seduced in to
dependency bloat when writing Test:: modules, and you should pay extra
attention to avoiding it if possible.
This is especially so if you have a dependency on a Module::Build Test::
modules, which is going to want to instal
Chromatic wrote:
On Mon, 2005-11-14 at 12:45 -0800, Ovid wrote:
Yes, I can see that. I could actually have dropped Test::Differences
"eq_or_diff" and just used the "is_deeply" function from Test::More,
but when working with large data structures, there's just no comparison
between the two. I
Philippe 'BooK' Bruhat wrote:
Le mardi 15 novembre 2005 à 15:23, Chris Dolan écrivait:
After reading some of the insightful comments posted on my blog, I've
been convinced that the private tests should be included in the CPAN
distribution, but disabled in some way (perhaps via a file extensi
David Golden wrote:
Adam Kennedy wrote:
What about a special environment variable, like RUN_PRIVATE_TESTS?
I've been working on a concept of taggable tests on some of my larger
commercial stuff, integrating with the Test::More skip() function, and
some form of environment variables
Michael
There's existing work happening in this area you may want to get
involved in. We even have a draft XML schema that does exactly what you
are talking about.
Go read http://ali.as/pita/
Then come hang out on irc://irc.perl.org/#pita
Adam K
Michael Peters wrote:
Hello all,
I'm in th
Do you still think that YAML is a good intermediate format choice? Do you think
an integration with other standard utilities to produce YAML would be possible
(prove, etc)?
YAML has a few ... issues. :/
I've laid them out before at http://cpanratings.perl.org/dist/YAML
Brian has said that the
A. Pagaltzis wrote:
* Adam Kennedy <[EMAIL PROTECTED]> [2005-11-23 01:40]:
And XML was designed for, and still remains VERY good at, doing
neutral format data interchange.
Another option if you want a lightweight format for structured
data is JSON. XML is very nice for doc
.
Adam K
Michael Peters wrote:
Adam Kennedy wrote:
Michael
There's existing work happening in this area you may want to get
involved in. We even have a draft XML schema that does exactly what you
are talking about.
Go read http://ali.as/pita/
Definitely an interesting project. It i
It's not magic, there is an option in RT for the old owner to give it
away (which solves a subset of cases) but for me at least it was counter
intuitive.
The hideously old version of RT on rt.cpan.org is being replace shortly,
and I imagine that Jesse will have way of taking maint changes into
For some variety, you might want to take a look at the JavaScript
implemention of the Test::* family, which we managed to build
asyncronous testing into, so you can do things like onTimeout
pseudo-threads that will happen asyncronously from your main testing.
Now granted, that doesn't deal wit
I'm looking at writing a system a little similar to CPAN Testers.
http://ali.as/pita/
I'll be announcing the project properly once I have some basics in
place, but the part of it I'm caring about today needs to run through...
Makefile.PL
make
make test
sudo make install
...and capture the ou
Kirrily Robert wrote:
Does anyone else find that SKIP: { } blocks bugger up the debugger?
I'll be happily bouncing on the "n" key to get to round about the
vicinity of the failing test, and then blam, it sees a skipped test and
just fast-forwards to the end.
K.
Yep
Actually, eval doe
Tyler MacDonald wrote:
Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> wrote:
For CPAN smokers based on CPAN::YACSmoke, the answer is: test the
presence of the AUTOMATED_TESTING environment variable. See also
the following page for more details:
http://search.cpan.org/dist/CPAN-YACSmoke/lib/CP
Anyhow, I haven't added the stats about whether a report is from
automated testing as you can't tell unless the test is using YACSmoke
as it adds a tag line in the report. Incidentally, Adam it would be
worth you doing the same with PITA, so these sorts of stats could be
gleaned in the future.
S
OK, I'll make sure there's some level of tagging about that in the reports.
Adam K
Barbie wrote:
On Tue, Jan 17, 2006 at 06:06:50AM +1100, Adam Kennedy wrote:
At the moment all our output is structured XML files, so at some point I
need to write an XSL to translate it back down into
Yes, CPAN can be a pain; however (kw|qu)alit(ee|y) is not meant to be
a metrics of how easy to install a module is, but rather of whether it
is possible to build something strong upon it, and to do so quickly
and easily. (Or am I mistaken?)
I disagree. A lot of the kwalitee metrics support best
Chris Dolan wrote:
On Jan 27, 2006, at 12:01 PM, Tels wrote:
On Friday 27 January 2006 18:48, Chris Dolan wrote:
On Jan 27, 2006, at 11:23 AM, Tels wrote:
Basically something like CPAN, but with much less network traffic
and much
less hassle for a user. Bonus points if it gives you stuff pre-
I think this would be rad:
- PPM becomes part of the perl core
- All CPAN packages are built to into PPDs automatically on common
platforms
- PPM is extended to allow installing into non-root locations
This would allow non-perl people to install perl packages much easier,
without having
My point is just that what makes PPM so good is that it doesn't futz
about with compiling code and running tests. It just installs the
code and goes home.
But then so does apt-get install libfoo-perl.
The installation is environment specific.
It's just that ActiveState provides a relatively c
James E Keenan wrote:
Steffen Schwigon wrote:
Quite often -l (to read from lib/) is enough, depending on your module
build complexity. For -b you have to call ./Build before "prove",
which can be annoying and/or difficult to remember.
I'll have to try that out. My modules all use MakeMaker ra
Graph::Easy installation failing here with YAML 0.50 (newer versions of
YAML seem to be uninstallable at the moment due to Class::Spiffy +
Spiffy + Test::Base install failures...
Any suggestions?
Adam K
Nicholas Clark wrote:
On Fri, Jan 27, 2006 at 11:50:49PM -0800, chromatic wrote:
Let me save you the trouble of writing it to find the biggest problem right
now: fairly broken automated testing systems that can't even *run* the
Build.PL file *or* the compatibility Makefile.PL yet send FAIL rep
Knocking off points for fails, however, might be due to things that are
completely idiosyncratic. For example, anyone whose module depended on
a test module that used Test::Builder::Tester when Test::Builder changed
and broke it could get dinged.
Does this really tell us anything about actu
t.
So needs_lib entries result in a debian module using libfoo on Debian,
or on RPM, or etc...
Adam K
A. Pagaltzis wrote:
* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-28 09:00]:
If a Perl module needs libfoo then it should be stated in the
metadata somewhere so that the binary pa
A. Pagaltzis wrote:
* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-28 16:20]:
More to the point, it should lead people to spend more time
looking into WHY their module isn't installing, and help us nail
down the critical modules in the CPAN toolchain that have
problems.
Sounds to me
A. Pagaltzis wrote:
* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-28 17:15]:
So do have any additional specific objections, or are we up to
"grumble, just fucking do it then, but I won't care" :)
Actually, I like the effort, even if I share some of the concerns
of the p
(*If* the author fixes the problem. I still can't get my patches for
Sub::Uplevel high enough in Schwern's queue.
Have you considered offering to take it over, or just co-maint the
module for one or two releases? He's given away modules before to people
that have more time to give them love t
Changing these HTTP like codes, might okay for an internal
representation, but would require ALOT of work to change several CPAN
modules and ensure all the testers upgraded. There is also the fact that
all existing reports are in the system and not going to change. Although
I may have misunderstoo
Sébastien Aperghis-Tramoni wrote:
Adam Kennedy wrote:
That said, I'd also like "I need libfoo 1.41" declarations and other
similar things, so we can really make the auto-packagers work some
hardcore magic.
/me takes the Net::Pcap maintainer hat
I'd really like to see
Sébastien Aperghis-Tramoni wrote:
Adam Kennedy wrote:
Could you have a look at the COOKBOOK section of the Module::Install
docs on CPAN, is that File::HomeDir example sort of what you would need?
Module::Install... 1) I'm allergic to this module, 2) I want to keep
the backward compatib
Yitzchak Scott-Thoennes wrote:
On Fri, Jan 27, 2006 at 03:42:58PM +0100, Tels wrote:
On Thursday 26 January 2006 15:26, Thomas Klausner wrote:
I just uploaded Module::CPANTS::Analyse to CPAN. MCA contains most of
the previous Kwalitee indicators and some code to check if one
distribution tarbal
Yitzchak Scott-Thoennes wrote:
On Fri, Jan 27, 2006 at 03:42:58PM +0100, Tels wrote:
On Thursday 26 January 2006 15:26, Thomas Klausner wrote:
I just uploaded Module::CPANTS::Analyse to CPAN. MCA contains most of
the previous Kwalitee indicators and some code to check if one
distribution tarbal
=> '0.80';
build_requires 'Test::More' => '0.47';
install_share;
auto_install;
WriteAll;
---
which creates the following
META.yml
---
no_index:
directory:
- inc
- t
generated_by: Module::Install
Except for the little fact that you have to bundle Module::Install in all
of your modules and need not to forget to add inc/* to MANIFEST -
Graph::Easy::As_svg increases from 27K to 47K gzipped
That concerned me for a little while as well.
But then someone pointed out to me that disk space
David Golden wrote:
Adam Kennedy wrote:
And therein lies the problem.
Working out when a dependency is important and when it's useless, or
vanity, or lazyness (good or bad) or whatever requires a human
judgment call.
So we can't really do anything about it.
Is it OK to us
And for the record, there are modules with incorrect C
concerning the Perl version. For example, some ask a Perl 5.005
while they perfectly work on 5.004, like File::Temp and
Test::Reporter. That's how I can send CPAN Testers reports
under 5.004:
http://testers.cpan.org/show/Net-Pcap.html
And t
David Cantrell wrote:
Adam Kennedy wrote:
A testing system should only be sending FAIL reports when it believes
it has a platform that is compatible with the needs of the module, but
when it tries to install tests fail.
So how, then, do I tell the testing system "this module only
brian d foy wrote:
In article <[EMAIL PROTECTED]>, Adam
Kennedy <[EMAIL PROTECTED]> wrote:
And if there is a problem with Module::Install, you have to update all
your dists with the new version - solve one problem, create two new
ones :)
But if there is a problem with EU::
1 - 100 of 330 matches
Mail list logo
