Hi Ken
On 31/07/16 19:09, Kenneth Ölwing wrote:
Hi Ron, thank you for responding!
If you don't mind, I have some follow up questions and comments :-)
Sure.
First a question about deps and how I treated them - maybe you can have
some advice on that too...
Most simply see, my comments in Makefile.PL. But in short: I've set my
deps to NOT request a specific Perl version, and for those dependencies
I do know I have, I've set them to '0'. This is since that while I've
developed this on a specific Perl and specific extra modules, I could
put that in, but obviously there's a whole range of combinations that
will work (including that some distros appear to have some deps I have
in their core, while others have not). So I figured, rather than
blocking out everything but a very narrow combination (or trying to
figure out boundaries myself), I 'allow' everything, with the intent
that as bug and test reports happen it can be refined.
Does this approach look reasonable?
I'd say yes, if you don't have a long history of dealing with Perl
module. But ... here are my notes on pre-req modules available:
o Pre-req (prereq) checkers:
- Module::Used, App::pmcheck, pmcheck
- Perl::PrereqScanner
- Module::Depends::Intrusive
- CPAN::FindDependencies
- App::mymeta_requires scans MYMETA.*
- Dist::Requires
- Devel::TraceUse tells which modules use which modules
ATM I use a home-grown couple of scripts which combine to use
Perl::PrereqScanner.
> At first, I was surprised by this proposal, since I often use
App::Ack (https://metacpan.org/release/ack),
> but the examples in the docs make a good case for having this module
too available to us.
I wasn't aware of that module, but yes, I think they serve different use
cases.
OK.
> Some Suggestions:
>
> o Move the pod tests into xt/author, and make any modules used to
test pod optional,
> so end users can install the module even if there are failing pod tests.
> Ah, I see running the tests that it requires AUTHOR_TESTING.
> Excellent, but could be a little bit better.
Ok, sounds reasonable, although I'm hoping you can clear up a few things
I don't quite grasp...
I used module-starter to get a template, so I initially had an xt dir,
which was new to me. Is there a common wisdom as to how conveniently run
them? I.e. in the spirit of 'make test' I figured 'make xtest' would
make sense, but no go. I can't find anything else premade in the
makefile to achieve this so I'm either not looking hard enough
or...something else :-). I understand there are ways to add my own
targets in Makefile.PL so I'm assuming that is the approach I should
take but just checking so I'm not missing something obvious...maybe
there is a common wisdom for running 'xt' tests very simply?
There used to be a simple way to do this, when many of us used
Module::Build, and hence shipped Build.PL:
perl Build.PL; ./Build; ./Build authortest
As it happens, I also shipped Makefile.PL.
But now that Module::Build is deprecated, and kicked out of core, I've
had feedback asking me not to skip both Makefile.PL and Build.PL, so I
zapped the latter.
The authortest incantation does not work with Makefile.PL. But there is
an easy way, from the module's dir:
prove -lv tx/author
And normally, instead of running perl Makefile.PL; make; make test, I
just use prove -lv t (same as prove -lvt), to test t/*.t.
Also, note that in some of the regular tests I do make use of
conditional around $ENV{RELEASE_TESTING} - I utilize SQLite to verify
Yes, I saw that.
that my query language works and gives the same results as a comparable
SQL query. That however, is not necessary for an end user, and it adds a
dependency on DBI/DBD::SQLite which isn't really needed for the module
per se so I make sure to work around that. Technically I guess such
tests could go into xt, but since I already have the entire test
infrastructure running there it makes sense to keep the code where it is
- it should be invisible in end user tests. I assume this is alright &
in the spirit of things?
Ahh, but it won't be invisible to pre-req scanners. So I suggest moving
it to xt/author.
If you have modules used just for testing, they can go in t/lib, but
make sure you tell Makefile.PL not to index them. I can't immediately
give you the syntax for that..
> o Change search.cpan.org to metacpan.org.
Admittedly, I haven't researched this...can you elaborate on why (or
point to a good resource)? Not at all opposed, it's just that I've
always used just CPAN so I'm not clear on what MetaCPAN brings to the
table.
MetaCPAN.org is much newer code, and has many features, including a API,
so it has quite a few benefits.
> Other than that, got for it!
Thank you, I'll take a stab at the stuff above first and then proceed.
Sounds good.
--
Ron Savage - savage.net.au
