Re: Sometimes MakeMaker won't make.

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

Re: RFC: Test::JSON

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

Re: RFC: Test::JSON

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

Re: Private tests

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

Re: Private tests

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

Re: TAP as XML

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

Re: TAP as XML

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

Re: TAP as XML

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

Re: TAP as XML

. 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

Re: RT Permissions

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

Re: Flexible testing

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

Injecting functionality into Test::Harness without needing to touch it...

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

Re: SKIP blocks and the debugger

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

Re: how to detect that we're running under CPAN::Testers?

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

Re: how to detect that we're running under CPAN::Testers?

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

Re: how to detect that we're running under CPAN::Testers?

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

Kwalitee in your dependencies (was CPAN Upload: etc etc)

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

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

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-

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

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

Re: Dependency trees

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

Re: Test Script Best-Practices

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

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

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

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

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

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

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

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

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

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

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

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

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

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

(*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

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

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

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

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

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

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

Re: Fwd: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

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

Re: Fwd: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

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

Re: YAML and Makefile.PL (was various topics)

=> '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

Re: YAML and Makefile.PL (was various topics)

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

Re: Fwd: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

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

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

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

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

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

Re: YAML and Makefile.PL (was various topics)

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::

Re: YAML and Makefile.PL (was various topics)

chromatic wrote: On Monday 30 January 2006 20:40, Adam Kennedy wrote: Incremental releasing is a toolchain problem. Having to rerelease more than one module and making every one of my users upgrade every module that uses this tool -- not just my one or more modules -- rather than making

Re: YAML and Makefile.PL (was various topics)

chromatic wrote: On Monday 30 January 2006 20:40, Adam Kennedy wrote: Incremental releasing is a toolchain problem. Having to rerelease more than one module and making every one of my users upgrade every module that uses this tool -- not just my one or more modules -- rather than making

Re: YAML and Makefile.PL (was various topics)

A. Pagaltzis wrote: * Adam Kennedy <[EMAIL PROTECTED]> [2006-01-31 07:50]: There isn't really any very good way (that I can see at least) to ensure that an end-user gets an update to EUMM/MB, just the module packager. So maybe that is the fundamental problem that should be addresse

Re: YAML and Makefile.PL (was various topics)

A. Pagaltzis wrote: * chromatic <[EMAIL PROTECTED]> [2006-01-31 08:20]: Perhaps CPAN/CPANPLUS should check for updates? Maybe just add EUMM+MB to Bundle::CPAN? (Does CPANPLUS have an equivalent?) Regards, But then how are you going to make Bundle::CPAN trigger when there's a critical failu

Re: [Module::Build] [RFC] author tests

The trouble is, EVERYONE wants to add just one more little dependency (me included *cough*Params::Util*cough*). I'll make you a deal. Write this up. Then exhaustively test it on every single Perl platform (50ish?) and every Perl version back to 5.004, including a random collection similarly w

Re: [Module::Build] [RFC] author tests

* copyright.t - Ensures that there is a "Copyright ".([localtime]->[5]+1900) somewhere in every .pm file. Will break 11 months from now. * distribution.t - Relies on Test::Distribution, which is not in my prereq list snipped ones that need your personal files, you are certainly right there

Re: [Module::Build] [RFC] author tests

chromatic wrote: On Thursday 02 February 2006 10:04, Tyler MacDonald wrote: A. Pagaltzis <[EMAIL PROTECTED]> wrote: I was just gonna say. It???s pointless for anyone but the author to check POD or test coverage. I agree about the POD coverage. But if I got a different level of cod

Re: [Module::Build] [RFC] author tests

environment variable to enable for release testing? It also has the nice property of being an imperative command when you say it. "Testing system, test release!" Adam K A. Pagaltzis wrote: * Adam Kennedy <[EMAIL PROTECTED]> [2006-02-03 02:45]: But I don't know that I like di

Re: Binary distributions

Tyler MacDonald wrote: Offer Kaye <[EMAIL PROTECTED]> wrote: Why not start off by providing ppm.cpan.org (as the OP suggested for linux distors), or something similar? There are many modules that I want to use where the PPM version provided by ActiveState or some other repository is badly of out

Re: Default tests, beta testing, etc.

Beta testing - CPAN tracks intra-module dependencies, and does automated testing, but only on released modules. It would seem useful to allow an author to upload a "beta" version of their module, and then run the tests of a dozen or so modules that depend on it. This way, you would gain

Re: IPC::Run or something else?

David Golden wrote: Tamas Dober wrote: I'd like to test that that a batch file (starting a Java app) gives me the expected output or not. Could you please help me what direction I should go, what module should I use? I've had good experiences with IPC::Run3. It's pretty lightweight and intu

Re: Binary distributions

n 0.17 . According to http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/IO-All-0.33.txt it is not being built because Spiffy failed it's tests. According to Spiffy's log, *it* did not build becuase Scalar-List-Utils failed to build... Which is the same module that both Adam K

Re: Binary distributions

But I'm not really too worried any more, the CamelPack means it's much easier not to just install from source than use the PPM system. s/not/now/ sigh Adam K

Re: Binary distributions

Offer Kaye wrote: On 2/6/06, Adam Kennedy wrote: But I'm not really too worried any more, the CamelPack means it's much easier not to just install from source than use the PPM system. s/not/now/ Installing from souce == compiling every module that needs it... How is that *ea

Re: Test::Builder feature request...

Geoffrey Young wrote: hi all :) there's a feature split I'm itching for in Test::Builder, etc - the ability to call is() and have it emit TAP free from the confines of plan(). not that I don't want to call plan() (or no_plan) but I want to do that in a completely separate perl interpreter. for

Re: Test::Builder feature request...

This works: ---test.pl--- use Test::More tests => 1; my $Test = Test::More->builder; my $counter = $Test->current_test; print qx!perl t/response.pl!; $Test->current_test($counter + 1); But why 1? Why not 5? or 10? __END__ ---response.pl--- use Test::More no_plan => 1; Test::More->bui

Re: Test::Builder feature request...

Randy W. Sims wrote: Adam Kennedy wrote: Randy W. Sims wrote: Adam Kennedy wrote: This works: ---test.pl--- use Test::More tests => 1; my $Test = Test::More->builder; my $counter = $Test->current_test; print qx!perl t/response.pl!; $Test->current_test($counter + 1); Bu

Re: Network Testing

Although I have no practical experience with this (yet) the latest versions of the qemu emulator would appear to support the setting up of multiple running emulated systems that occupy a common network and could thus probably be poked into doing what you want. But it might take a while to set

Request for Comments: Package testing results analysis, result codes

I'm starting to get a bit closer (waiting on a test images and some last testing to be done) to finishing the initial PITA test cycle (and thus be able to do an initial release) and so I'm starting to do some prep work now for the next stage, which is to start to assemble some infrastructure ar

Re: Request for Comments: Package testing results analysis, result codes

While an interesting idea, I forsee two challenges to doing this... Firstly is that it might turn an otherwise normal result into something else, with no clear rule. It makes a judgement call that some level of testing is good or bad, which isn't really the place of an installer to call. The

Re: Request for Comments: Package testing results analysis, result codes

(Andreas J. Koenig) wrote: On Sun, 19 Feb 2006 22:22:20 +1100, Adam Kennedy <[EMAIL PROTECTED]> said: > 1. Broken or corrupt packaging. > A bad tarball, MANIFEST files missing. Make sure you verify that all files in the distro are readable. Reject if the permissio

Re: Request for Comments: Package testing results analysis, result codes

Regarding the blow, I may have been a little unclear on the layout of the points. The first line is the name of the error. Following lines are meant to provide details to help clarify what it means. Barbie wrote: On Sun, Feb 19, 2006 at 10:22:20PM +1100, Adam Kennedy wrote: 2. Incompatible

Re: Request for Comments: Package testing results analysis, result codes

Now 100% skips, THAT could potentially be interesting, or maybe TODOs. But then I don't necesarily know why it would be worthy of a different result code. Is there metadata stored apart from these result codes? If so it might be useful to just store the statistics on skips. Assuming this

Re: MAKE SCHWERN PAY!]

Michael G Schwern wrote: On 2/20/06, Steve Peters <[EMAIL PROTECTED]> wrote: Remeber you are helping a good cause by getting and extra $500 to the Perl Foundation, but you're also helping to tear Schwern away from Worlds of Warcraft for a few minutes to write the check. Sad but true. Now

Re: Request for Comments: Package testing results analysis, result codes

As for not testing suite at all, I'm not sure that's cause for an UNKNOWN, probably something else. If you see an UNKNOWN in CPAN test reports, it means that 'make test' returned "No tests defined". This is the result of no test suite at all. It should be caught, and may be cover by point 2.

Re: META.yml feature for autotesters?

Tyler MacDonald wrote: How does everybody feel about making this a defined "feature" in the META.yml spec? Something like: optional_features: - automated_testing: description: Automated testing of all of this package's features requires: DBD::SQLite2: 0 If

Re: META.yml feature for autotesters?

While a META.yml file provides a good description of what is required, the dependencies WILL change once the Metafile.PL runs. Actually, that should read "will often change, 90% of the time not turning on the dynamic_config flag in the process". So while we are on the subject of META.yml, I t

Re: META.yml feature for autotesters?

Randy W. Sims wrote: Adam Kennedy wrote: To give you some more data points, imagine the automated testing additions applied only on Win32. How would you then specify the deps? #187 on the TODO list for M::B is to implement the dEx[1] (Dependency EXpression) language for inserting complicated

Re: What is the Value of t/0-signature.t?

I've started to do a little bit of work on Module::Signature. The main problem seemed to be that it will install even if it's configuration cannot be confirmed, when I think it might be preferable to not install at all if it cannot be confirmed. I've also move Module::Signature into the Modul

Re: Show-stopping Bug in Module::Install and the Havoc it Created

Tels wrote: Moin, On Friday 10 March 2006 12:26, Shlomi Fish wrote: Hi all! We had a discussion here about the pros and cons of using Module::Install with "use inc::Module::Install" in the Makefile.PL, and bundling it along. Well, now a showstopping bug happened in Module::Install and several

Re: "Erroneous" CPAN Testers Reports

A. Pagaltzis wrote: * David Golden <[EMAIL PROTECTED]> [2006-03-13 23:05]: This issue also has frustrated me for some time, but I don't think that we should be considering deleting reports. Reports are just facts -- they have no value basis. Yes, people may make judgments about the robustness o

Re: "Erroneous" CPAN Testers Reports

Even better would be adding two more states so that you can distinguish between prereq-failure, build-failure, test-failure and ok. Well actually I tried to sit down the other day and work out how many distinct types of success/failure events there might be, for use in PITA. The number came

Re: New kwalitee metric - eg/ directory

David Landgren wrote: Hey! It's been over two months since we last had one of these suggestions! I did battle with a module that shall remain nameless the other day. I had a difficult time figuring out how to use it. In times like these, I like being about to go to the build directory and p(aw

Re: Activestate and Scalar-List-Utils

The main reason this is hapenning is that it's not currently possible to update CORE packages in ActivePerl, so any module that depends on a CORE package can be suffering from this. This problem will persist until it becomes possible to update core packages in ActivePerl. It's certainly not an id

Re: Best Practice for testing compilation of scripts

http://search.cpan.org/src/ADAMK/ThreatNet-Bot-AmmoBot-0.10/t/01_compile.t That function should probably be changed to use FindBin instead of updir() calls. Actually, by modern standards I'd consider that a pretty half-assed. Mostly for the fact it's a highly unix usage. If it was doing it

Re: Upgrading core modules on Windows

The only problem with this is that it only deals with CPAN.pm itself. The problem with locked files is wider than this. Imagine for example that you have Windows mod_perl or some other long-running program holding a lock on the modules. I had a similar idea last week, where maybe we could hav

Re: Upgrading core modules on Windows

Im not sure if you realized, but you can install YVES/ex-ExtUtils-Install-1.3701.tar.gz and assuming you have Win32API::File installed this stuff will be handled properly. This package is a proposed split off of the installation code in the ExtUtils::MakeMaker bundle. We are waiting on Schwe

Re: What is the Value of t/0-signature.t?

Audrey Tang wrote: On 3/17/06, chromatic <[EMAIL PROTECTED]> wrote: Do you mean that it's valuable only for the author to run (perhaps during disttest) and rarely useful for the user to run during installation? Aye. Though I can imagine users who'd like to run them as well... This is after

Proposed kwalitee metric: installer_not_executable

From my understanding, one of the little idiosyncrasies of Makefile.PL/Build.PL installers (including MI variants of both) is that in order to make sure that the Makefile and Build use the correct perl installation, you should always be explicitly running M/B.PL with the perl you want to instal

Re: [PATCH] Forking tests with Test::More

Without saying you shouldn't be sending them here, but as an aside... Who told you to send patches to the list? Is there a reason that the rt.cpan.org queue is no longer useful? Adam K Tassilo von Parseval wrote: Hi, I was told that Test::More patches should now go to this list so here we go

Re: [PATCH] Forking tests with Test::More

Tassilo von Parseval wrote: On Tue, Mar 28, 2006 at 09:47:54AM +0100 Fergal Daly wrote: A far simpler solution (that I've posted before recently) is to output test "numbers" like .1.1 .1.2 .1.3 .2.1 .2.2 .1.4 etc where the first number signifies the thread/process and the second is just an i

Re: [PATCH] Forking tests with Test::More

What's changing the protocol? As I understand it from http://search.cpan.org/~petdance/Test-Harness-2.56/lib/Test/Harness/TAP.pod the test number must be a number. It does refer specifically to it having to start with a digit, but I'm assuming that by number it means [1-9]\d* .1.2 would

Re: [PATCH] Forking tests with Test::More

Tassilo von Parseval wrote: Hi, I was told that Test::More patches should now go to this list so here we go. The attached patch serves as a draft for enabling test-scripts that fork without the test-counter getting confused. It does so by using a Storable imaged shared between the processes. Th

Re: Module::Build and installing in non-standard locations

There are a number of ways to do this. The most simple is: use strict; use warnings; use File::HomeDir; my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo' ); Not that I wish to be a pedant about this, but only so people keep it in mind... This installer will crash with a non-

Re: [OT] TDD only works for simple things...

The one thing I don't really like very much about TDD is that in a loosely typed language I suspect if suffers. Specifically... - It can test the things you know that work. - It is good when testing the things you know that don't work (its strong point) - It is not good for testing the things

Re: [PATCH] Forking tests with Test::More

Well, the author of Test::More seems to differ on that: Although personally I'd think I'd read into that, that forking shouldn't cause problems, with "and you should be able to emit test output on both sides" as a bonus extended DWIM fea

Re: Testing with Apache/mod_perl

I'd also add a small warning in that Apache::Test does seem to want to dominate the entire test suite (run everything from TEST) and so may not be as suitable in cases where you have 50-500 test scripts already, and you just want a few to work with Apache::Test and a normal Makefile.PL built wi

Re: [OT] TDD only works for simple things...

thing than a "it will never get there" thing. Adam K chromatic wrote: On Thursday 30 March 2006 07:32, Adam Kennedy wrote: In contrast, as I hear chromatic express it, TDD largely involves writing tests in advance, running the tests, then writing the code. Not quite. It means wr

Re: [OT] TDD only works for simple things...

Tels wrote: Moin, On Thursday 30 March 2006 17:32, Adam Kennedy wrote: [snip] Calling ->method( \"" ) or ->method( \undef ) or ->method ( sub { die "foo" } ) and a dozen other things like that is intentionally provoking that code into blowing up. This are go

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

Randy W. Sims wrote: Adam Kennedy wrote: >> There are a number of ways to do this. The most simple is: >> >> use strict; >> use warnings; >> >> use File::HomeDir; >> my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo&#

Re: Testing with Apache/mod_perl

Oops, didn't reply to all... A-T is nothing if not flexible. That the _option_ to trade off speed for flexibility isn't as easy as I personally would like it to be, rather than that it doesn't address any given known scenario. really, I don't know what you're saying, but it sounds vaguely li

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

ugh, sorry, WAY too early in the morning. If the installer needs a module in order to run, it has nothing to fall back on to supply that module for it. Any surrounding client doing a recursive installation can't fix it, unless what it can do when the installer runs and says that the distributi

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

demerphq wrote: On 3/31/06, Adam Kennedy <[EMAIL PROTECTED]> wrote: If an installer can't INSTALL under battle conditions, it is failing it's primary missing. Personally I think its worth being a touch more specific with your language. I dont see Module::Build's job to b

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

> Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the "installer" doesnt work? Yes, absolutely. Adam K

Re: Module requirements (was: Module::Build and installing in non-standard locations)

A. Pagaltzis wrote: * demerphq <[EMAIL PROTECTED]> [2006-03-31 10:10]: Something like dieing on a use warnings statement in the makefile or whatever to me constitutes a pre-build failure, not an install failure. `s/installer/build script/gi` on Adam’s post and his points still stand. The wha

Re: Module requirements (was: Module::Build and installing in non-standard locations)

A. Pagaltzis wrote: * Adam Kennedy <[EMAIL PROTECTED]> [2006-04-01 04:10]: I guess the problem is that in Makefile.PL strictly speaking you're not _really_ meant to be doing any building of stuff. That's supposed to be what you do in make. So one solution to your problem

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

demerphq wrote: On 4/1/06, Adam Kennedy <[EMAIL PROTECTED]> wrote: > Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the "installer" doesnt work? Yes, absolutely. So you would file a bug with ExtUtils::MakeMaker or Module:

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

chromatic wrote: On Saturday 01 April 2006 03:41, demerphq wrote: So you would file a bug with ExtUtils::MakeMaker or Module::Build when the pre-build script that accompanies a script has a syntax error in it? Don't forget with every distribution that marked that distribution as a dependency

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

demerphq wrote: On 4/2/06, Adam Kennedy <[EMAIL PROTECTED]> wrote: demerphq wrote: On 4/1/06, Adam Kennedy <[EMAIL PROTECTED]> wrote: > Similarly if somebody has an error in their Build.PL or Makefile.PL are you going to say that the "installer" doesnt work? Yes,

Re: Show-stopping Bug in Module::Install and the Havoc it Created

Yitzchak Scott-Thoennes wrote: On Sat, Mar 11, 2006 at 10:20:29AM +0100, Tels wrote: B when it breaks, end-users cannot fix the problem for themselves, they need to bug the author and he has to release a new version. (Good luck with that with sparsely maintained modules...) Last time this hap

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

I know, now people will come out of the wood and say that they have that old system, and no, they can't upgrade Perl etc, never touch a running system etc yadda yadda. But what the heck do you then try to upgrade modules on said system when you didn't want to "touch the system"? To quote pos

  1   2   3   >