Re: Restructuring check scripts
Russ Allbery wrote:
> Raphael Geissert writes:
>> Russ Allbery wrote:
>
>>> In that case, what if we made each check a first-class module, with use
>>> base, and then for each check we can then call the constructor,
>>> providing a default one and allowing the test to override if it needs
>>> to do setup. Then the standard Perl DESTROY method can handle
>>> tear-down if one is needed. Oh, and then run can be an object method,
>>> and the default implementation can be to use introspection to find all
>>> check_* methods and run each of them. Then, all we have to do is
>>> modify the existing check scripts to ignore the first argument to run,
>>> and they keep working as-is, but we can rewrite them to use check_*
>>> methods at our leisure.
>
>> That was sort of what I did on the patchset I submitted. Except for the
>> tear-up part.
>
> Yeah, I think I'm just slow. :) Or I wasn't paying attention to your
> explanation the first time around. It makes a lot more sense now. Sorry
> about that! For some reason, I didn't think about data shared between
> checks.
I probably wasn't clear enough back when I made the proposal. No worries.
>
> Hm, if we're going to make use of that, we should also ensure that the
> checks are called in a predictable order or can declare dependencies on
> each other or something... although I suppose they could use a separate
> sub to gather the data and use the same technique that Lintian::Collect
> uses to cache it.
That's why I suggested turning Lintian::Collect into the canonical data
interface. By moving all the data collecting logic into a separate module
it will be easier to later support multiple threads (which I hope at some
point we do) as the locking mechanism would be needed there and not on
every check.
>> Glad the old mbox was archived. Back in May I rewrote some parts of the
>> branch to avoid creating the objects and calling run() directly.
>
> I am sorry it's taken me so long to respond! I'll try not to disappear
> like that again.
>
Np. No matter how hard we try there are time we simply can't get to work on
something ;-).
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Reply to: