Re: Time for a Revolution

Why? Oh, why do people lately insist on offering up enticing tidbits of /what is to be the next great ordained (core|6pan|etc)/ without offering the community a chance to comment or participate? =( Randy. Well, in this case two reasons. Firstly, although I have what I hope is a tentative man

Re: CPANDB - was: Module::Dependency 1.84

A. Pagaltzis wrote: * Tels <[EMAIL PROTECTED]> [2006-07-14 02:40]: announced to early - now everybody tells me how I have to implement it and why my way wont work You were saying Adam’s way is inferior to your way. I disagreed. That’s about the size of it. I agree my way is inferior, especia

Re: CPANDB - was: Module::Dependency 1.84

Plus, I planned to use YAML because it creates a _much_ less heavy overhead and dependency chain. Using SQLite or similiar is what really creates the problems with CPANTS - you cant just access the raw database without the front-end. Erm, I'm not sure I get you here. The main problem with all th

Re: Time for a Revolution

Unlike what others said, "core" perl shouldn't be the vehicle for this, most likely, given the more stringent support and backwards compatibility. We want to be able to change the composition of "PerlPlus" overtime, and once things go into core, they're pretty stuck. I should note for the rec

Re: TAP diagnostic syntax proposal

To summarize. What TAP uses is irrelevant, as long as it works. What the Harness prints is relevant, but easy to fix any time. No worries about TAP 1.0 vs. TAP 1.1, just download the new Test:Harness from CPAN and everything will work. Right? Wrong. Well, maybe... Sometimes it could be ye

Re: TAP diagnostic syntax proposal

~ Pragmatics: TAP 2 must allow users to understand all relevant information. if there's language or a method of presentation or other WTDI that is understood by a wider audience, it must be used over one understood by a smaller audience. i hope this categorization makes sense, and you find it hel

Re: CPANDB - was: Module::Dependency 1.84

. (simple by having the database being superior to every other hack thats in existance now :-) I even got so far as to do a mockup v0.02 - but then went back to playing Guildwars. Is this a project that would be of general interest? At YAPC::NA, Adam Kennedy mention that he wanted to try to make

Re: TAP diagnostic syntax proposal

Geoffrey Young wrote: However, most perl tests don't care about TAP, they use Test::More and Test::Harness and happen to exchange data via TAP. If Test::More and Test::Harness decied to use "YAP" (YAML Anything Protocol? :), then most applications would probably never notice. most _perl_ appli

Re: TAP diagnostic syntax proposal

Whoa whoa whoa slow down there folks... Some people seemed to have misrecognised those keys as YAML. It was NEVER meant to be YAML. The idea was to use something more like MIME headers. We all agreed that we DIDN'T want the format to be too heavy, and going with MIME or MIME-alike seemed the

Re: Old and broken versions of Module::Install

James E Keenan wrote: Steffen Mueller wrote: You can find a complete (and somewhat current) list of problematic modules at http://steffen-mueller.net/mi_old.html Thank you very much for this public service! Indeed. Adam K

Re: [Slightly OT] Understanding Software Licences [was Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]]

From my interpretation, what he said was "I don't care to understand licenses enough so I don't want to be bothere with it." Now I think this is a rather small-minded approach to this issue, which I think is very bad. Perhaps, the response to Ovid about it instead of this message was not appropr

Re: Module Signatures

Andreas J. Koenig wrote: On Fri, 07 Jul 2006 10:02:00 +1000, Adam Kennedy <[EMAIL PROTECTED]> said: >> (What would be marginally worth it is having PAUSE sign distros. At >> least we can assure that the CPAN mirror didn't tamper with the >> files, which I thi

Re: Old and broken versions of Module::Install

I understand the concerns with M::B itself; that’s why I always use `create_makefile_pl => 'traditional'`. Indeed, and if you insist on using Module::Build, that is most certainly the sanest approach. Adam K

Re: Module Signatures

(What would be marginally worth it is having PAUSE sign distros. At least we can assure that the CPAN mirror didn't tamper with the files, which I think is the most likely "attack" on CPAN.) Frankly, that's the best idea I've heard yet. It would at least be "trivial" to implement compared to

Re: Old and broken versions of Module::Install

But you’re not catching me dead using an installer that requires me to pay attention to its development and to push up new versions of my distros in response to its bugs. There are far better ways to waste my time. Good, because that's entirely the point I've been trying to make ever since I st

Re: CPAN and META.yml: no_index dir vs directory

Hmm, it looks like there is a strong correspondence between distros using 'directory' and distros produced by Module::Install. There goes Adam, breaking rules and rebelling against established conventions. Hehe. Just kidding. I think I like 'directory' better myself anyway. Sigh, one of these

Re: CPAN and META.yml: no_index dir vs directory

B/BL/BLM/Win32API-Registry-0.27 I can move this one pretty easily too, it needs a new release anyway. R/RC/RCAPUTO/POE-0.3502 R/RC/RCAPUTO/POE-Component-Client-Keepalive-0.0801 I'm pretty sure Rocco will move next release as well. Adam K

Re: On "Gaming" CPANTS, and a Kwalitee Suggestion

Define "some" please :) Ricardo has said he is, for example. And, "improve compatibility" - with broken systems? OMG. :) You mean we now don't sign packages anymore just because someone isn't able to check the signature? The right way is to tell the user to fix their borken system, not to

Re: TAP extension proposal: test groups

If we don't have some way of signifying the end of a group in TAP then it removes a chunk of the utility for the people writing things that generate TAP - since everybody has to write their own checks that groups actually output the number of tests that they should. If we have an end-of-group

Re: TAP extension proposal: test groups

That seems like a problem too but the one I'm trying to get at is 4 no plan, with groups If your script exits prematurely after one of the groups, the harness will not notice because everything looks just fine. The solution to this is not to use "plan, with groups" because then you have to coun

Re: TAP extension proposal: test groups

Fergal Daly wrote: On 02/07/06, Adam Kennedy <[EMAIL PROTECTED]> wrote: > There's no way to declare a top-level plan. That is, I can't say how > many groups of tests I'm going to run so there's effectively no plan, One point that Andy was extremely insista

Re: TAP extension proposal: test groups

There's no way to declare a top-level plan. That is, I can't say how many groups of tests I'm going to run so there's effectively no plan, One point that Andy was extremely insistant on, and I think Schwern and I agree, is that the main plan is ALWAYS the total number of tests for the entire t

Re: TAP extension proposal: test groups

Fergal Daly wrote: On 02/07/06, Adam Kennedy <[EMAIL PROTECTED]> wrote: Fergal Daly wrote: > It looks like it's only one level of nesting. Any reason not to go the > whole hog with something like > > ..1 > OK 1 > ..2 > ...1 > OK 2 > OK 3 > ...2 > OK

Re: TAP::Harness

Michael G Schwern wrote: On 7/1/06, Yuval Kogman <[EMAIL PROTECTED]> wrote: Please look at Test::TAP::Model and the horrrible hooks it goes through to make things work. I'd love to have a SAX like event-handler model for TAP through TAP::Harness so that I can construct Test::TAP::Model obje

Re: TAP::Harness

The most up-to-date Test-Run code is here: http://svn.berlios.de/svnroot/repos/web-cpan/Test-Harness-NG/ I don't mind giving Subversion access to the repository to anyone who registers in http://developer.berlios.de/ and is either a CPAN contributor, or has sent me one patch for me to commit.

Re: TAP::Harness

* How can I help? Provide use cases, what would you want to do with Test::Harness if you could? What are you doing with Straps? What features do other testing systems (JUnit, for example) have that you'd like to see in Perl? Once I post the design, pick it to pieces. I know I mentioned it to

Re: TAP extension proposal: test groups

Fergal Daly wrote: It looks like it's only one level of nesting. Any reason not to go the whole hog with something like ..1 OK 1 ..2 ...1 OK 2 OK 3 ...2 OK 4 ..3 OK5 I believe the conclusion here was that because demand for nested groups appeared to be extremely limited, to START with just th

Update from YAPC::NA

I noticed a lot of people weighed in with non-bug posts to Andy's bug fix request. I just wanted to note that Wednesday we had a PITA/Test::Builder/Testing BOF at which a bunch of people had an hour long talk about the structure of Test::et-al TAP and various other topics. I think we addressed

Re: Continuous testing tools

Michael G Schwern wrote: On 6/9/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote: * Adam Kennedy <[EMAIL PROTECTED]> [2006-06-09 18:35]: > Sorry for the lack of information, but PITA's design is fairly > ambitious, Hmm, I just saw this: http://googleresearch.blogspot.com/20

Re: Continuous testing tools

Hi Andrew I know it's somewhat vapour at the moment, and I'm keeping somewhat quiet, but the new post-Audrey'fied PITA design is aiming at exactly what you have described. Initial deployment targets include a pugs smoker, parrot smoker, and CPAN Testers 2. Of course, I have no idea how you

Re: Continuous testing tools

Sorry for the lack of information, but PITA's design is fairly ambitious, and until the core testing loop is completed, absolutely every other part of it would block waiting for me to finish. So I've kept things mostly under wraps. With the core almost done (we've had to scrap a major componen

Re: Unintended consequences

d so I haven't been chasing her about it. I'm done venting now. Adam K Michael G Schwern wrote: On 5/27/06, *Adam Kennedy* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: I tell you what, I'm going to add the same code to all 100+ of my modules. And wha

Re: Unintended consequences

demerphq wrote: On 5/26/06, Ovid <[EMAIL PROTECTED]> wrote: - Original Message > From: Adam Kennedy <[EMAIL PROTECTED]> > > Andy Lester wrote: > > Here's an example of why I'm not real excited about CPANTS: > > > > http://communit

Re: CPANTS is not a game.

Oh, and by the way... What the hell is the "run" thing in the latest run... is the run just half-way through or something? Adam K

Re: CPANTS is not a game.

I'm now settled in my new job (and new appartment), the new and improved CPANTS is running on a new server (provided by yi.org, thanks again to Tyler MacDonald!). So basically all the time I can spend on CPANTS will go into new tests (eg a check if used modules (minus stuff in Module::Co

Re: Unintended consequences

Andy Lester wrote: Here's an example of why I'm not real excited about CPANTS: http://community.livejournal.com/perl/120747.html Ironically, posted by someone that also makes all her modules phone home at install time. Adam K

Re: Changing permissions on temporary directories during testing

See the test suite for File::Flat, I put a ton of work into making sure it worked, and a lot of code doing filesystem stuff. Adam K James E Keenan wrote: Let's say that I'm writing a test suite for a Perl module which creates files and then, optionally, moves those files to predetermined dire

Re: SVN::Web

Nik Clayton wrote: Nik Clayton wrote: Hi Adam, [...] Mea culpa -- that was supposed to be an e-mail. N That's totally fine. :) I used Insurrection because it was there... and I didn't know of anything else that worked. And once you get past the fact that it's impossible to install, it d

Re: SVN::Web

Nik Clayton wrote: Hi Adam, Adam Kennedy wrote: Phase N is my company, and http://svn.phase-n.com/svn/cpan is the collaborative subversion repository for my code, that now includes PPI, which you've expressed a desire to have bugs fixed in I believe a number of times. I see you

Re: Fwd: Insurrection account created

Phase N is my company, and http://svn.phase-n.com/svn/cpan is the collaborative subversion repository for my code, that now includes PPI, which you've expressed a desire to have bugs fixed in I believe a number of times. http://use.perl.org/~Alias/journal/29327 Did you not get the email about

Re: Proposed kwalitee metric: consistent_newlines

It does work very well though and I prefer it to fighting with the MakeMaker docs to figure out how to get it to install a data file in the right place :-) Perl has language-level support for uuencoding/-decoding data (check `perldoc -f pack`). You can take advantage of that to keep your binary

Re: Proposed kwalitee metric: consistent_newlines

Paul Johnson wrote: On Wed, May 03, 2006 at 11:36:53AM +0200, A. Pagaltzis wrote: Am I missing something, or won’t all of these will cause problems with Module::Signature? The thing is that it doesn’t matter how perl sees the file; what matters is how Module::Signature sees the file, and to my

Re: Proposed kwalitee metric: consistent_newlines

Ovid wrote: --- Adam Kennedy <[EMAIL PROTECTED]> wrote: So I'd like to propose the following for inclusion. Metric: consistent_newlines The distribution is awarded a point IF for ALL text files within the distribution EACH file contains EITHER exclusively unix newlines OR exclus

Re: Proposed kwalitee metric: consistent_newlines

The Perl::Critic thing could be tricky though. One of the very few things PPI does that isn't round-trip safe (actually, the ONLY thing) is localise the newlines for the files it opens. And given that I live on a hybrid Win32/linux setup, PPI is also one of the very few things that is actuall

Proposed kwalitee metric: consistent_newlines

In the gap before Kwalitee shows it's head and we get another CPANTS update, I thought I'd throw a new one into the ring. I've twice now hit problems relating to SIGNATURE files. SPECIFICALLY, I see problems with files that have _mixed_ newline types. That is, part of the file is unix newlines

Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz

Michael Peters wrote: Shlomi Fish wrote: On Sunday 23 April 2006 22:35, chromatic wrote: On Sunday 23 April 2006 12:05, Shlomi Fish wrote: This debate demonstrates why a plugin system is necessary for a test harness. No, it demonstrates why a well-defined test output protocol is useful. I a

Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz

chromatic wrote: On Sunday 23 April 2006 15:46, Michael Peters wrote: How about a good TAP parser module that does nothing but parse TAP. Then it could be used in all kinds of test harness permutations. That's exactly what I want and precisely why I think a well-defined TAP is more important

Re: Non-Perl TAP implementations

stion. Adam K Fergal Daly wrote: On 4/18/06, Adam Kennedy <[EMAIL PROTECTED]> wrote: The aformentioned change to Test::Builder broke 3 different Test-Testing modules that relied on it. 3? I only know of 2 - Test::Builder::Tester (which scrapes and broke) and Test::Tester (which does

Re: Non-Perl TAP implementations

Geoffrey Young wrote: Adam Kennedy wrote: Schwern made one small change in the STDERR format, and the recursive cascade of failing test-testing modules hit something like 3000 CPAN distributions. While I agree that this caused problems, those modules were relying on a format that was not

Re: Non-Perl TAP implementations

Schwern made one small change in the STDERR format, and the recursive cascade of failing test-testing modules hit something like 3000 CPAN distributions. While I agree that this caused problems, those modules were relying on a format that was not spec'ed out or documented. That is irrelevant

Re: Non-Perl TAP implementations

chromatic wrote: On Monday 17 April 2006 18:50, Ovid wrote: The only problem I see with that is the occasional buffering errors I see on my Mac where the STDERR and STDOUT don't line up. Agreed. Is it too late to send everything to STDOUT where it belongs? Unfortunately, it probably is too

Re: Non-Perl TAP implementations

Ovid wrote: --- David Wheeler <[EMAIL PROTECTED]> wrote: Test.Simple—JavaScript. It looks and acts just like tap, although in reality it's tracking test results in an object rather than scraping them from a print buffer. http://openjsan.org/doc/t/th/theory/Test/Simple/ Tracking the resul

Re: Module requirements

chromatic wrote: On Friday 07 April 2006 10:48, demerphq wrote: On 4/7/06, chromatic <[EMAIL PROTECTED]> wrote: eval { dereference_somehow( $thingie ) } Sure, thats what i was saying elsewhere too. But I dont consider that a reasonable solution. Consider if dreferencing it means executing

Re: Module requirements

David Cantrell wrote: chromatic wrote: On Thursday 06 April 2006 17:53, Adam Kennedy wrote: UNIVERSAL::isa/can when called as a function does a very specific thing, and one that is often misunderstood. ... and never correct, in the face of proxy objects, blessed objects, overloading, and ties

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

I use 5.8.0 as minimum, but for unicode I think it should be 5.8.1 - but I am unsure. COuld you give a reason for why specifically 5.8.3? Actually, in consultation with Audrey and other $experts, Perl::MinimumVersion applies a 5.8.4 minimum whenever it sees any mention of Unicode. I believe

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

chromatic wrote: On Wednesday 05 April 2006 14:09, Adam Kennedy wrote: And now in return, we have new modules that changes the way EVERYBODY else's code works, and changes the meaning of that code instead, so Test::MockObject gets less spurious bug reports. You mischaracterize the situ

Re: Generator for Modules-Installing Makefiles

Wow, what great timing :) To add to your use case, on the project I'm currently working on, we have 5 CPAN-style dists, probably 10 by the time we are done, but they all need to be installed in a particular order. Due to the peculiarities of the situation, doing a CPAN::Inject style setup is

Re: Module requirements

I suspect that many of these are API driven. Programming should be fun and using an API that doesn't "fit" isn't fun. As a result people go write their own stuff that they feel is easier/faster to use. This is the flip side of impatience and hubris. E.g. CPAN search found 510 "Simple", 8

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

chromatic wrote: On Wednesday 05 April 2006 02:02, Adam Kennedy wrote: But it's also why UNIVERSAL::isa/can and people adding higher-version dependencies below their existing lower-dependency modules is bad. The code used to work just fine, and now it doesn't. This is a strange

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

chromatic wrote: On Tuesday 04 April 2006 21:57, Adam Kennedy wrote: Seeing as the worst support cases are about 10 years in a variety of countries and situations, I think that is what we should be aiming for for highly used CPAN modules. Which last time I checked is now 5.005.something So I

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

chromatic wrote: On Tuesday 04 April 2006 10:32, Tels wrote: There is also the point that supporting ancient Perls means you can't use all the new, wonderfull features that were added to later versions of Perl, like our, warnings etc. This to me is the biggest problem. After 6 years, is it

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

Ricardo SIGNES wrote: * "H.Merijn Brand" <[EMAIL PROTECTED]> [2006-04-04T10:40:39] And then still people make more of the same. Take Getopt::Long. A perfect and very functional module. Full of features, matured, and actively maintained. Now go look at CPAN, and see how many people either do not

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

Who was it who was working on the global CPAN dependency graph, to figure out what module was dependent on what? Whatever became of that? I think hard numbers that stand on their own merits are about the only way to get new stuff into core. Let the early adopters try out non-CPAN low-level mo

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

Many module authors set a design objective of making their modules "dependent only on core modules". This is a comment that I see on a regular basis. When I hear or read that, I always wonder if the author realised that "core modules" is something dependant on the Perl distribution version.

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

Anyway, i just wanted to add this because I dont think that you can take it for granted that all perl5porters believe the core module set should be as restricted as possible. I dont. I believe that the core should contain out of the box enough support for the various platforms that perl runs on th

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

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)

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

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

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

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

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

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

  1   2   3   >