Bug#501688: dh-make-perl ignoring build_requires in Makefile.PL

[Paul Fenwick]

G'day Damyan,

Damyan Ivanov wrote:

> Oh. My apologies. You already mentioned that URL. Sorry for not paying 
> enough attention.

Actually I only just pushed my repo.  ;)  I may have mentioned some of my
other projects that find their way onto github, I've got quite a few there.

> I agree with you that breaking the present monolith approach into 
> sub-modules each of which does one simple is good.

Well, if there's no objections to splitting things up into modules, then
this is definitely preferred over cute hacks involving __FILE__ and $0.

> What bothers me more is the 'input' and 'output' of dh-make-perl. We 
> don't test if a given function returns what is expected when given some
> arguments. We give a CPAN ('input') dist and then get a debian/ directory
> added to it with various files in ('output'). How could this be achieved
> if the only testing instruments we have are ok(), is_FOO() etc?

> A testing framework could be useful for both the current and the new,
> rewritten, code so if you know some tricks that do not rely on the
> codebase being modular and clean, please don't hold them for yourself :)

I'm reading through the code now, and I understand your concerns.  A lot of
things, like our %opts hash, just leak into subroutines.  Likewise, there
are a number of essentially global variables such as $pkgname, $srcname, and
so on which have all sorts of overrides which can be set, and which would
ideally be contained in a hash or object which is passed to subroutines that
need them.

As for how we can test dh-make-perl using Perl's recommended testing
techniques, well, it's conceptually not too hard.  If we've got our code
modularised, we can load each module and ensure each individual subroutine
is doing what it's supposed to.  An example of this can be found in my
'unit-testing' branch at:

	http://github.com/pfenwick/dh-make-perl/tree/unit-testing

I've moved one of the easiest functions from dh-make-perl into its own module:

http://github.com/pfenwick/dh-make-perl/tree/unit-testing/lib%2FApp%2FDh_make_perl.pm

and provided some tests for basic correctness:

  http://github.com/pfenwick/dh-make-perl/tree/unit-testing/t%2Freadme.t

and a trivial test launcher:

  http://github.com/pfenwick/dh-make-perl/tree/unit-testing/test

Note that readme.t includes a failing test marked as TODO; we'd like our
create_readme() function to check its arguments, but it doesn't yet.  In
theory, to do more unit testing, we just add more tests like these.

Once this is in place, integration testing ends up being very similar,
except we're calling higher level functions rather than lower level ones.
Eventually we're calling our main() function with testing arguments, and
making sure it does what we expect.  This is where the sample dists come in
handy, especially if we have known-correct debian directories to compare
against.

What makes things hard at the moment is so much of the code is tightly
coupled.  Everything looks inside %args, rather than having it passed in.
Likewise, I can see that $meta just bleeds into a few subroutines rather
than being explicitly passed.  This sort of tight coupling makes testing and
maintenance challenging, because tracing how these variable are set and used
be be difficult.  Ideally anything that's being used by a subroutine is
passed to it as arguments (or is contained in its object if we're using OO).

> Well, we can implement the META.yml usage now (possibly adding to the 
> ugliness) and deal with the rewrite in slower pace as the time permits.

Hmm, I've just looked at the code for extracts_depends, and it really really
*should* do the right thing.  It first tries to use
Module::Depends::Intrusive, which tries to do odd things (which may fail)
with Makefile.PL / Build.PL, and then falls back to Module::Depends, which
should just look in the META.yml to figure out what's going on.

I'd be inclined to swap these steps.  If something provides a META.yml, we
should believe that first.  In any case, I'm going to take a poke around and
see what I can find.

All the very best,

    Paul

P.S. Many thanks for the git mirror of the subversion repo.

-- 
Paul Fenwick <pjf at perltraining.com.au> | http://perltraining.com.au/
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681