Re: How to specify a data file location for tests
I think I solved this now by adding the missing dependency on
Plack::Middleware::Session. It's used only in the app.psgi file - so
Dist::Zilla did not find it automatically. The reports now are all green
confirming that this was the problem:
http://cpantesters.org/distro/P/Plack-Middleware-Auth-Form.html
What about the error message? I think I have an explanation for this. When
I do 'do $psgi_file' the perl interpreter tries load the
Plack::Middleware::Session from the many directories in @INC and fails each
time - this sets $! to 'No such file or directory' - and it is not cleared
later. $@ is still set by the failing 'do' as described in the
documentation - but since I was checking $! first I was getting tripped.
Thank you all for helping me with this problem and David Golden in
particular for putting me on the right track.
Cheers,
Zbigniew
On Sat, Mar 5, 2011 at 9:15 AM, Zbigniew Lukasiak zzb...@gmail.com wrote:
On Fri, Mar 4, 2011 at 4:57 PM, David Cantrell da...@cantrell.org.ukwrote:
On Fri, Mar 04, 2011 at 09:16:14AM -0500, Shawn H Corey wrote:
On 11-03-04 01:54 AM, Zbigniew Lukasiak wrote:
my $psgi_file = File::Spec-catfile( 't', 'app.psgi' );
I thought the tests were done in the t directory. If so, then the file
its looking for would be: t/t/app.psgi
Nope. The cwd is normally that into which the distribution was
unpacked. I do that sort of thing all the time.
I think I can confirm that now. I changed the code to:
if( -d 't' ){
chdir 't';
}
else{
warn 'I am in: ' . getcwd();
}
my $psgi_file = 'app.psgi';
my $app = do $psgi_file || die $! ? Cannot find '$psgi_file': $! :
Cannot compile '$psgi_file': $@;
but I don't see 'I am in: ' in the test results:
http://www.cpantesters.org/distro/P/Plack-Middleware-Auth-Form.html
Still half of the tests fail.
Any idea what this can be?
--
Zbigniew
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/
How to specify a data file location for tests
Hello, I keep getting reports like this one: http://www.cpantesters.org/cpan/report/8824a82a-45ea-11e0-afb0-adca6bb533f3: Cannot find 't/app.psgi': No such file or directory at t/main.t line 9. Lines 8 and 9 of t/main.t are: my $psgi_file = File::Spec-catfile( 't', 'app.psgi' ); my $app = do $psgi_file || die $! ? Cannot find '$psgi_file': $! : Cannot compile '$psgi_file': $@; The 't/app.psgi' file is in the distribution: http://cpansearch.perl.org/src/ZBY/Plack-Middleware-Auth-Form-0.006/t/app.psgi It is not a big deal - I can put app.psgi inside the test file. But a separate file is also a good example and I think there should be some official way to do that. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
Misleading error message - lack of zlib reported as no libxml2 (compiling XML::LibXML)
I a m not sure where I should report that - it looks like a quite generic bug. I tried to install XML::LibXML on a quite new system - it failed because of no libxml2 - but I installed it and it was still failing with the same error. Then I run perl Makefile.PL DEBUG=1 and voila: ... LD_RUN_PATH=/usr/lib:/lib cc -shared -O2 -L/usr/local/lib -fstack-protector Conftest.o -o blib/arch/auto/Conftest/Conftest.so \ -lxml2 -lz \ /usr/bin/ld: cannot find -lz ^^^ collect2: ld returned 1 exit status make: *** [blib/arch/auto/Conftest/Conftest.so] Błąd 1 system call to 'make test 'OTHERLDFLAGS='' failed at Makefile.PL line 470. no libxml2 not found ^ ... underlinings mine After installing sudo apt-get install libzip-dev - all worked OK. This is perl 5, version 12, subversion 3 (v5.12.3) built for x86_64-linux -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
The format of the L formatting code
I keep getting a POD test failure report from one NetBSD box: http://www.cpantesters.org/cpan/report/79291528-0863-11e0-ba74-a517e8014913 I think the line numbers are reported for whole paragraphs (for example 109 in WebNano.pm does not contain L at all), so here they are: Every WebNano application has at least three parts - the application class, at least one controller class and the Lapp.psgi|http://search.cpan.org/~miyagawa/Plack/scripts/plackup file (or something else that uses Lhttp://search.cpan.org/dist/Plack/lib/Plack/Runner.pm run the app). LPSGI environment|http://search.cpan.org/~miyagawa/PSGI/PSGI.pod#The_Environment This is a wrapper around LTemplate::Tiny|http://search.cpan.org/~adamk/Template-Tiny/lib/Template/Tiny.pm - 'Template Toolkit reimplemented in as little code as possible'. I think all of these comply with the syntax in http://perldoc.perl.org/perlpod.html: Or you can link to a web page: Lscheme:... Ltext|scheme:... Links to an absolute URL. For example, Lhttp://www.perl.org/ or LThe Perl Home Page|http://www.perl.org/. Am I missing something? -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
Preventing PAUSE from indexing examples
How do you prevent PAUSE from indexing example classes? I know about the trick with splitting the package declaration into two lines - but this is both ugly and in conflict with the purpose of newbie friendly examples. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
Re: Preventing PAUSE from indexing examples
On Sun, Oct 17, 2010 at 11:40 AM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 da...@cpan.org wrote: http://p3rl.org/CPAN::Meta::Spec#no_index Thanks a lot! By the way - is there a way to specify that in dist.ini? -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
Re: Preventing PAUSE from indexing examples
On Sun, Oct 17, 2010 at 11:51 AM, Zbigniew Lukasiak zzb...@gmail.com wrote: On Sun, Oct 17, 2010 at 11:40 AM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 da...@cpan.org wrote: http://p3rl.org/CPAN::Meta::Spec#no_index Thanks a lot! By the way - is there a way to specify that in dist.ini? OK - now I feel stupid: http://search.cpan.org/~mjgardner/Dist-Zilla-Plugin-MetaNoIndex-1.101550/lib/Dist/Zilla/Plugin/MetaNoIndex.pm -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
Two modules with the same name (MooseX::SimpleConfig)
Am I missing something? http://search.cpan.org/~bobtfish/MooseX-SimpleConfig-0.07/lib/MooseX/SimpleConfig.pm http://search.cpan.org/~chilts/SRS-EPP-Proxy-0.21/lib/SRS/EPP/Proxy/SimpleConfig.pm They do seem to be nearly identical copies - but I guess this can quickly change if one of them is updated. I thought the CPAN indexer would cry loudly in such a case. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
Re: The CPAN Definitive Tags Spec
On Sat, Aug 7, 2010 at 11:04 AM, Shlomi Fish shlo...@iglu.org.il wrote:
On Saturday 07 August 2010 04:50:29 Aristotle Pagaltzis wrote:
* Ovid publiustemp-moduleautho...@yahoo.com [2010-08-06 23:50]:
I can't say I've really been paying attention here, but while
some tags (requires C compiler) seem like they might be
reasonable, other tags such as black_magic seem highly
subjective. And the source_filter tag seems to belong in the
black_magic category.
The ${OS}_only tags only seem haphazard and like a bad place to
put that information… why is there no `vms_only` or such? What if
something works on FreeBSD and Linux but not MacOS? Is MacOS
a true Unix?
It seems like a rather random collection.
Hmmm I agree with what you say. Perhaps a works_on_linux,
works_on_macosx, works_on_windows, etc. tags will be better and people
will be (naturally) able to specify more than one tag.
First of all - I like that - I mean that would really help when
searching for modules - but I am afraid that can easily slip into the
direction of works_on_ubuntu_linux_with_perl5.12.1.
And while we are at that - how about using test reports as tags?
Totally brainstorming now - but then maybe tags would specify what the
author intends to - like declaring that his module should work on all
POSIX systems - and for actual confirmation we could use the test
reports?
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/
Re: Module uploaded - whats next?
On Fri, Dec 11, 2009 at 4:37 PM, Rene Schickbauer rene.schickba...@gmail.com wrote: Oh, come on boys. Don't start a flame war. You both have valid points: Catalyst is a mature framework AND it does not fit everyones purpose. Isn't that the Perl way, the reason why we have TIMTOWTDI in the first place? I think a discussion about the why's could be interesting and insightful - unfortunately I have to agree that the posts above are mostly about influencing and not much about truth seeking. Is that ever possible? If we agree that no - it is not - then TIMTOWTDI is indeed the last resort for sanity. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
Re: Module uploaded - whats next?
On Fri, Dec 11, 2009 at 5:31 PM, Rene Schickbauer rene.schickba...@gmail.com wrote: Hi! I think a discussion about the why's could be interesting and insightful - unfortunately I have to agree that the posts above are mostly about influencing and not much about truth seeking. Is that ever possible? I don't think so. Everyone thinks and works a little different. So, a feature in a software could be THE feature for one but the killer bug for someone else. This is similar to Whats the best editor? or Whats the best operating system?... Countless flamewars have been fought (and lost) over questions like that. As WOPR in Wargames pointed out: 'A strange game. The only winning move is not to play'. So far, the only two questions in that category humanity was able to solve were What is the best drink in existance? which is the Pangalactic Gargleblaster and What is the meaning of life, the universe and everything? which is fourty two (and for which we are STILL waiting for the exact wording of the question to make sense of the answer). I pretty much convinced that you are right - but still I would like to try :) Maybe the way forward is not to talk about what is the best thing - but rather about the design choices being made. My hope is that when we spell them precisely we'll see the tradeoffs involved and it'll be easy to see why different situations call for different sides in these tradeoffs. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
Optional Features and down-stream modules
Optional features are not well suited for automated install. They impose questions on the install - but what is more important they generate problems when for down-stream modules that rely on the optional features. There is no easy way to specify this - and also if those optional features depend on installation of some optional prerequisites - then the down-stream module have no way to determine which ones of the optional prereqs are needed for the feature it depends on (and if that optional feature relies on another optional feature in one of the prerequisites - then the situation is completely non-transparent for the down-stream module author). -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/
