On Thu, Feb 26, 2009 at 8:32 PM, Michael G Schwern <[email protected]> wrote:
> Craig A. Berry wrote:
>>> The important thing is the core change from running the ext/ tests manually
>>> to
>>> using each module's own "make test". This will make integrating and
>>> developing dual life modules far easier by eliminating a key difference in
>>> how
>>> ext/ and CPAN modules are developed.
>>
>> Hmm. This only makes any difference for modules that distribute their
>> own libraries that are only used for testing, right? It looks like
>> ext/Test-Harness/t/lib is the only one like that currently. Add
>> Module::Build and ExtUtils::MakeMaker when they get moved to ext/,
>> maybe a couple others.
>
> It's a general purpose problem that effects all the ext/ modules.
You mean affects, not effects.
> Most tests
> have some special code to accommodate the duality of core vs CPAN testing.
> Usually its just this:
>
> BEGIN {
> if ($ENV{'PERL_CORE'}){
> chdir 't';
> unshift @INC, '../lib';
> }
> }
>
> But it will effect any test that needs to know its position relative its
> source tree, usually to read another file or load a module in the source tree.
Is that really considered a best practice? I know a lot of smart
people do that, but in my experience, this sort of cleverness often
leads to things going wrong.
> CPANPLUS and CPAN are good examples off the top of my head. But it's not
> limited to just finding stuff in their own t/lib.
CPANPLUS tests use FindBin to locate themselves and find their
friends. It's not immediately clear the tests would need any changes
to move over to ext/ (though it is big and complicated and can't be
known for sure without trying it).
> Rather than look at this as "its an exception for a few modules in ext" turn
> it around. All the dual lifed modules currently scattered around lib/ are the
> exceptions. If we can pull them back together and put them in ext it will
> make integration easier both for p5p and the CPAN maintainers. This is the
> base assumption I'm working under.
>
> The more we do this, the more we're going to find "exceptions", the more hacks
> we have to put into place and what's going to wind up happening is we're not
> going to want to move things into ext. Making ext/ as much like the normal
> module process as possible smooths out the transition.
I'll try to keep an open mind and assist where I can, but from where I
sit this is just shifting time and attention away from important
things like fixing known bugs and getting releases out the door toward
putting out all the fires that will inevitably arise from breaking
something that is known to be stable and working.
