RT Permissions
When one person takes over the module of another on CPAN via co-maint a first-come tranfer, what happens to the RT stuff? I'm in the process of taking over Net::Blogger from Aaron Straup Cope (ASCOPE). I'm already set for first-come in PAUSE for that module now. There are open RT issues that I'd like to resolve, then close of course, but it's not obvious how, or if I can. Is this a timing thing, or does RT go by the original author only? Thanks, -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: RT Permissions
Andy Lester wrote: On Fri, Dec 02, 2005 at 12:10:24PM -0800, Ovid ([EMAIL PROTECTED]) wrote: I've wondered about this myself. I've taken over Class::Trait but I can't take ownership of the RT requests. RT should do it automagically. Email Jesse directly if not. xoxo, Andy For which, first-come, or do all of the co-maints have full RT access as well? -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: RT Permissions
Andy Lester wrote: On Fri, Dec 02, 2005 at 12:10:24PM -0800, Ovid ([EMAIL PROTECTED]) wrote: I've wondered about this myself. I've taken over Class::Trait but I can't take ownership of the RT requests. RT should do it automagically. Email Jesse directly if not. xoxo, Andy Which Jesse... Vincent? -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: CPAN Testers results
Ovid wrote: Hi all, I've noticed that http://search.cpan.org/~ovid/HOP-Parser-0.01/, amongst other modules, has no CPAN test results appearing even though CPAN tester reports are coming in. I've seen this for other modules, too. Is there an announced reason for this I missed or is something down? Cheers, Ovid I've often wondered this myself. It seems like it builds up some sort of delta or count of reports, then does a build; as to avoid rebuilding stats for every report email that comes in. Or, somethings just broken. :-) -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Test Suite Slowing Down My Development
Ovid wrote: The code is designed well enough that adding new features is quick and easy. Unfortunately, whenever I need to change my code I fire up a Web server and view the results in the browser and then write the tests after I've written the code (this is closely related to When test-driven development just won't do). This is because XML and XHTML are just text. I need to see the output. I've been finding more and more that small changes in my code are making huge changes in the output and trying to continuously update the tests to exactly match the XML, XSLT and XHTML using Test::XML and XML::XPath has led to a serious productivity drop. I'm considering just using Test::WWW::Mechanize to do integration testing through a Web server I run in the tests. This will be much faster and allow me to get my development speed back up. However, I'd be skipping the unit testing of the output. I'll catch the bugs but it will likely take me longer to track them down. I feel your pain. The test suite for Handel has xml/tt output tests for its AxKit and Template Toolkit plugins. I've got oodles of template pages using the components whos output I compare to static .out files that contain the expected output. Everytime I write a new plugin, or a new tag in the plugin, I waste tons of time just writing the tests for them. So far, I've been good about writing the tests before I write the code, but it takes forever and I rarely get the tests right the first time. I'm curious to see what comes out of your question. I'm in the same boat. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: New kwalitee test, has_changes
Adam Kennedy 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 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. Adam K Would this look for Change OR ChangeLog? Both seem to be popular on CPAN. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: rantTesting module madness
Andy Lester wrote: Usually, Test::* modules are only used for the test phase. I really don't understand the idea of only used for the test phase, as if the tests don't matter, or if there are levels of failure. Either they install OK on the target system, and you can use them with confidence, and they've done their job, or you're going to ignore the tests completely and then who needs 'em? It's like if I'm installing a washing machine, and I don't have a level. I can say Ah, I only need it for the installation, and it looks pretty level, so I don't need the level, or I can say I'm not using this appliance until I've proven to myself that the machine is level and won't cause me any problems in the future because of an imbalance. I've always thought tests passing should be a requisite of make by default. Make fails if tests fail. There should of course be a -skiptests to opt out of testing for those who insist on not doing it, but for the most part, if tests are so important like we the perl community say they are, then they should be run as part of make. Period. Not a popular opinion, but there it is. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Why are we adding more kwalitee tests?
Richard Clamp wrote: On 6 Sep 2005, at 08:10, Adam Kennedy wrote: So once you find out DBIx::Wango only passed 7 out of 23, it will go into the author's average, and if he ever looks presumably the competative spirit will kick in and he's fix some of the problems That's assuming that everyone is competitive. I'm not, and so I'm not about to crank out 62 new releases just because my distributions aren't up with the current fashions in cargo-culted tests. devils_advocate Then why bother replying to this thread or even paying attentionto CPANTS? /devails_advocate mini_rant The paraphrase Schwern, my bozo bit just flipped. I really don't get why the people (not specifically you) who don't agree with, don't care for, don't care about CPANTs or more CPANTS tests spend all this effort going off on why it's such a bad thing and why it shouldn't be done. If it serves no purpose for you, ignore it and go on with life; as apposed to spending email list cycles on a CPANTS-is-bad-why-are-we-doing-this diatribe. /mini_rant -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Why are we adding more kwalitee tests?
Andy Lester wrote: On Tue, Sep 06, 2005 at 09:12:43AM -0400, Christopher H. Laco ([EMAIL PROTECTED]) wrote: If it serves no purpose for you, ignore it and go on with life; as apposed to spending email list cycles on a CPANTS-is-bad-why-are-we-doing-this diatribe. It's not as simple as just ignore it if the result of your actions are that people stop uploading to CPAN, or new authors are steered away, for fear of scorn and ridicule. Why would they stop uploading? How would they, the new uploaders, even know about CPANTS? It's not like uploaded files automatically return a scathing email and an html response page that says your module sucks; failed CPANTS kwalatee. Go away. This is no different than CPAN Testers. I can upload dists till the cows come home. If my module failes every single cpan testers report, who cares? That doesn't stop or disuade people from uploading does it? Of course not, so why would CPANTS kwalitee be any different? -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Why are we adding more kwalitee tests?
Andy Lester wrote: On Tue, Sep 06, 2005 at 10:07:02AM -0400, Christopher H. Laco ([EMAIL PROTECTED]) wrote: Why would they stop uploading? How would they, the new uploaders, even know about CPANTS? It's not like uploaded files automatically return a scathing email and an html response page that says your module sucks; failed CPANTS kwalatee. Go away. I don't know. That's why I ASKED THE QUESTION of what will be done with the information about their results. Understood. I guess I'm ssuming that whatever is done with this information, it is not more or less harmful than testers reports or Rate-this-dist rankings. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Devel::cover bug?
Kevin Scaldeferri wrote: On Jun 3, 2005, at 1:40 PM, Paul Johnson wrote: Certainly. Of course, it's always possible and quite likely that there is a bug in my code somewhere. But there is also a chance that I am conflating two ops, since I have yet to come up with a way to uniquely identify an op (suggestions welcome). You're not running on 5.6.x are you? No, 5.8.x -kevin As I recall [I may be wrong], some of your snippets were under /5.8.0/... isn't 5.8.2 considered squirrelly (technical term) under Devel::Cover? Perl 5.8.0 and 5.8.1 will give slightly different results to more recent versions due to changes in the op tree. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Kwalitee and has_test_*
Adam Kennedy wrote: 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 of a 99_pod.t to my packaging system (less for kwalitee than that I've noticed the odd bug get through myself) why doesn't kwalitee just check the POD itself, rather than make a check for a check? Adam K Because they're two seperate issues. First, checking the pod syntax is ok for the obvious reasons. Broken pad leads to doc problems. Second, we're checkling that the AUTHOR is also checking his/her pod syntax and coverage. That's an important distinction. I would go as for to say that checking the authors development intentions via checks like Test::Pod::Coverage, Test::Strict, Test::Distribution, etc is just as important, if not more, than just checkong syntax and that all tests pass. Givin two modules with a passing basic.t, I'd go for the one with all of the development side tests over the other. Those tests listed above signal [to me] that the author [probably] pays more loving concern to all facets of their module than the one with just the passing basic.t -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Kwalitee and has_test_*
Tony Bowden wrote: On Thu, Apr 07, 2005 at 08:56:26AM -0400, Christopher H. Laco wrote: I would go as for to say that checking the authors development intentions via checks like Test::Pod::Coverage, Test::Strict, Test::Distribution, etc is just as important, if not more, than just checkong syntax and that all tests pass. 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. Tony That is true. But if you don't ship them, how do I know you bothered to check those things in the first place? [I don't think there is a right answer to that question by the way.] I'm just saying that the presence of those types of tests bumps up some level of kwalittee, and they should be left alone within CPANTS. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Kwalitee and has_test_*
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 I know you bothered to check those things in the first place? Why do you care? What's the difference to you between me shipping a a .t file that uses Pod::Coverage, or by having an internal system that uses Devel::Cover in a mode that makes sure I have 100% coverage on everything, including POD, or even if I hire a team of Benedictine Monks to peruse my code and look for problems? The only thing that should matter to you is whether the Pod coverage is adequate, not how that happens. I think you just answered youre own question, assuming you just agreed that I should care about whether your pod coverage is adequate. How as a module consumer would I find out that the Pod coverage is adequate again? Why the [unshipped] .t file in this case. The only other way to tell is to a) write my own pod_coverage.t test for someone elses module at install time, or b) hand review all of the pod vs. code. Or CPANTS. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: TestSimple/More/Builder in JavaScript
David Wheeler wrote: Greetings fellow Perlers, I'm pleased to announce the first alpha release of my port of TestSimple/More/Builder to JavaScript. You can download it from: http://www.justatheory.com/downloads/TestBuilder-0.01.tar.gz Very cool. Very sick. :-) OK, now whos gonna build JPANTS? :-) -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: [Module::Build] Re: Test::META
Ken Williams wrote: Since the 'build', 'test', and 'install' actions are considered the critical path for installing a module, I think it makes sense to warn (not die) during perl Build.PL when one of their required/recommended/conflict dependencies aren't met. Thereafter, only die/warn when running an action and its required/recommended dependencies aren't met. -Ken I'll show my lack of historical knowledge here, and this is swaying just a little off topic. If build, test, and install are considered the critical path, why was Build/make never changed to simple run test always as part of the builds success or failure? Just curious. In a way, I'd be much happier if 'perl Build' or 'make' outright failed if the tests didn't pass, just like if there was a c/linking error. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
Michael G Schwern wrote: [snip] Sticking with ExtUtils::MakeMaker. :-) [But where's the fun in that.] I know you're joking, but you've flipped my rant switch. I was. But at some level, I'm not. If after changing one dist to use M::B I have more issues than I started with [which was just checking the syntax of my manually edited META.yml], then there's no reason to move all of my dists; even if there are only 6 of them. However, the same could be said about my META.yml files period. They weren't broken; just incompleted. I'm the type of idiot that gets the urge to put everything pertinent I can into my META.yml files, even if E::M and M::B don't currently have the means to do exactly what I want. [snip] But it hasn't. And I only see a small number of people patching Module::Build. And there's tons of low hanging fruit available. What's going on here? One thing I see going on is that people are holding Module::Build up to rediculously high standards. Much, much higher than MakeMaker ever was. Anything Module::Build tries to do people still nit-pick it to death, and here's the horrible part, they don't generate much patches. I would think the same is true of any 'replacement' dist. I wonder if CPAN/CPANPLUS don't suffer from the same issue. Take dependency resolution. MakeMaker has one way to specify a dependency. MB has a whole spectrum. And yet people still want to fall back to MM's low resolution dep system because MB's isn't quite high enough. Take create_makefile_pl. Module::Build bends over backwards to be compatible with MakeMaker. It offers not one but THREE different methods of providing that. Hell, it'll even generate a Makefile.PL that will download MB for you! And yet when people encounter small problems with it the response isn't Here's a patch or even I'll just work around that for now. No, its I'm going back to MakeMaker where they'll likely have to do more work and more work arounds to achieve the same effect. Guilty as charged. See top comments. It's not 'going back', it's 'sticking with what already is in place'. I'd be all to willing to take a stab at patching test_requires and the ability to choose whether create_makefile_pl adds recommends: to PREREQ_PM or not during create_makefile_pl. But the former meant getting the META.yml spec updated as well, which didn't seam like something that would happen anytime soon. Maybe that's a bad assumption. [snip] The point is this. * Give MB a chance. * When you encounter a problem in MB, try to patch it. * Do not expect Ken and Randy to do all the work for you. * Do not immediately run back to the warm, familiar, utterly flawed embrace of MakeMaker. Thank you. This has been a rant. So back to M::B I shall go, and I'll make it do my bidding come hell or high patch water. smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
Michael G Schwern wrote: There is a create_makefile_pl option (see Module::Build::Compat) which does a fair job of creating a Makefile.PL functionally equivalent to your Build.PL. It comes in various flavors from passthrough (where it writes a Makefile which simply calls Module::Build functions) to a pure MakeMaker implementation. That's another gripe of mine about M::B and create_makefile_pl. It puts the requires AND build_requires in the PREREQ_PM in the Makefile.PL, which I won't want; nor do I think it right for everyone. Take Test::More for example. It's usually a build_requires and the other Test* things like Test::Strict, Apache::Test, etc are in recommends. Test probably won't run with Test::More, but skipping a few subtests based on recommends is ok. But I don't think build_requires should be a PREREQ_PM requirement at all. For that matter, it's not really clear what the expected outcome of a missing build_requires requirement is as far as CPAN/CPANPLUS is concerned. Flipping through the Makefile.PLs of your modules they look for the most part trivial and would be handled fine by create_makefile_pl. smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
Michael G Schwern wrote: On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote: That's another gripe of mine about M::B and create_makefile_pl. It puts the requires AND build_requires in the PREREQ_PM in the Makefile.PL, which I won't want; nor do I think it right for everyone. There is no build_requires or recommends equivalent in MakeMaker, nor will there be, so putting it into PREREQ_PM is the best thing to do. That's what every MakeMaker-based module on CPAN does after all. Its better than just dropping it and having the build fail. That's a matter of opinion; one I think should be left up to the person makeing Build.PL. Take Test::More for example. It's usually a build_requires and the other Test* things like Test::Strict, Apache::Test, etc are in recommends. Test probably won't run with Test::More, but skipping a few subtests based on recommends is ok. But I don't think build_requires should be a PREREQ_PM requirement at all. *scratch head* but if you don't have the modules necessary to BUILD the module (as opposed to those necessary to run it)... how are you going to build it? See definition below from the docs on what build_requires [ambiguously] means. Maybe there's some confusion here as to what build_requires means? Perhaps you're confusing it with the (possibly mythological) test_requires and test_recommends? Absolutely it's confusion. http://module-build.sourceforge.net/META-spec-new.html A YAML mapping indicating the Perl modules required for building and/or testing of this distribution. These dependencies are not required after the module is installed. So, to me this means something like Test::More. It absolutely has to be in place to some *.t files to ever work, or even load. Now granted the test may end up just skipping because Test::Strict isn't instealled. In that situation, I see Test::More just as required as strict.pm. Maybe this is my issue. To me, building and testing are two different things. I don't have to test. Ever. By I do have to build the module. build_requires is a bad place for test requirements, but recommends isn't right either. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
Randy W. Sims wrote: There is my unpublished CPAN::Metadata at: svn co http://svn.versiondude.net/randys/CPAN-Metadata/trunk/ CPAN-Metadata It reads, writes, and validates metadata according to the spec. It still needs a bit of work, and updates to the actual spec need to be formalized before it will be usefull. Thanks... Along the lines of converting to Module::Build...it went well until I started doing tests...things that worked now break, probably do to how they're now run... t\xsp.Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path So, I've sticking with ExtUtils::MakefMaker for the moment. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
Michael G Schwern wrote: On Sun, Mar 27, 2005 at 08:32:59PM -0500, Christopher H. Laco wrote: Along the lines of converting to Module::Build...it went well until I started doing tests...things that worked now break, probably do to how they're now run... t\xsp.Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path That's odd, its not where I'd have expected breakage. Want to post your MakeMaker and MB versions so we can poke at them? I rolled back. I'm have to reconsicrate my Build.PL tomorrow. I want to tinker a bit more tomorrow to rule out user stupidity. My bet is that the shebang -w in my *.t files are kicking in where they weren't before; pointing to a difference in how they're invoked between the two envorinments. Along those lines, CTRL-C, CTRL-D, and Terminate batch job.. Y never got me out of the loop: The path '' is not an absolute path. Please specify an absolute path My only recourse was to terminate the CMD window. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
Andy Lester wrote: On Mar 26, 2005, at 6:29 PM, Christopher H. Laco wrote: Is anyone aware of any existing code (aside from YAML) for grocking META.yml? Why are you changing it manually? Well, unless I missed something [likely], to add things after the module is created or updated. Changing requirements, recommends, and build_requires for starters. Sometimes no_index when new modules are added to dists. Changing from the default one create with: # http://module-build.sourceforge.net/META-spec.html #XXX This is a prototype!!! It will change in the future!!! X# to the more clean/proper YAML 1.0... -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
Michael G Schwern wrote: On Sat, Mar 26, 2005 at 07:52:45PM -0500, Christopher H. Laco wrote: Well, unless I missed something [likely], to add things after the module is created or updated. Changing requirements, recommends, and build_requires for starters. Sometimes no_index when new modules are added to dists. Changing from the default one create with: # http://module-build.sourceforge.net/META-spec.html #XXX This is a prototype!!! It will change in the future!!! X# to the more clean/proper YAML 1.0... MakeMaker has very rudimentary META.yml support and is unlikely to improve in the future. Module::Build, OTOH, can handle all this for you automatically. build_requires, recommends, etc... so if you like META.yml, switch to Module::Build. Switch to Module::Build anyway. Reading...reading...reading...reading..done. Still doesn't help with the no_index problem, but it looks interesting. Can dispatch($action, %args) be used to simulate dist = PREP to autogen the pod2text README? -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: TAP/Test::Builder in JS
David Wheeler wrote: Hi All, Is anyone aware of an implementation of Test::Builder/Simple/More and Test::Harness in JavaScript? The testing scene in JS appears pretty sad, but I don't want to do much in JavaScript without a nice testing framework. And Test::More would be my preferred way to go. (Yes, I know that there are JSUnit implementations, but that seems a bit heavy to me...). If not, would anyone like to help me work on one? Regards, David When you say test JavaScript, what kinds of files are we testing? Server side web scripting using JavaScript? Shell scripts files? -=Chris smime.p7s Description: S/MIME Cryptographic Signature
[RFC] Test::CPANTS
I have an itch. It just came to me while surfing PerlMonks and CPAN. I noticed the new Test::Strict module which keeps me honest by making sure I always 'use strict'. I'll be adding that to my modules this evening. [I wish is did use warnings too]. My second thought was wouldn't it be cool if there was something like Test::CPANTS in which I could always verify that my modules were at least at a kwalittee rating of x or more during make test? Any thoughts? I've looked at the CPANTS modules and it looks possible, and I'm willing to take a crack at it it anyone thinks it will be of some use. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: [RFC] Test::CPANTS
Sébastien Aperghis-Tramoni wrote: Christopher H. Laco wrote: I don't know if that answer your needs but Test::Distribution already performs several kwalitee tests on the modules and other files of a distribution. http://search.cpan.org/dist/Test-Distribution/ Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO Yeah, I had looked at that, but there are two things keeping me from using Test::Distribution: prereq Checks whether all use()d modules that aren't in the perl core are also mentioned in Makefile.PL's PREREQ_PM. I have a few modules that are optional; not declared in PREREQ_PM. Probably not a problem since they're evaled in. However, there are plenty of cases where I'm usin-ing one module that is a child of another parent, and the parent is in PRERQ, but the child wouldn't be. versions Checks that all packages define $VERSION strings. Onlt the main module package has a version; not all of the other packages. Maybe that's a bad thing? -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: [RFC] Test::CPANTS
Christopher H. Laco wrote: Sébastien Aperghis-Tramoni wrote: Christopher H. Laco wrote: I don't know if that answer your needs but Test::Distribution already performs several kwalitee tests on the modules and other files of a distribution. http://search.cpan.org/dist/Test-Distribution/ Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO Yeah, I had looked at that, but there are two things keeping me from using Test::Distribution: prereq Checks whether all use()d modules that aren't in the perl core are also mentioned in Makefile.PL's PREREQ_PM. I have a few modules that are optional; not declared in PREREQ_PM. Probably not a problem since they're evaled in. However, there are plenty of cases where I'm usin-ing one module that is a child of another parent, and the parent is in PRERQ, but the child wouldn't be. versions Checks that all packages define $VERSION strings. Onlt the main module package has a version; not all of the other packages. Maybe that's a bad thing? -=Chris And I don't gain a ton by only running 4/6 tests via only/not. smime.p7s Description: S/MIME Cryptographic Signature
