End of 2016 update on PyKF5 bindings

[Shaheed Haque]

HI,

On 6 January 2017 at 00:33, Stephen Kelly <steveire at gmail.com> wrote:
> Shaheed Haque wrote:
>
>>> It is my intention to add that and other databases which are currently
>>> 'missing', when
>>>
>>>  * We have some tests for them in the ECM repo
>>>  * We want to add bindings to a framework (in a KDE repo) which requires
>>> them
>>
>> To your first point, the bulk generator/compiler tools *are* test
>> tools as far as KF5 is concerned...they happen not to fit the
>> repository-aligned model because for my present purposes, I want to be
>> able to easily run them en-masse across /usr/include/KF5.
>
> Yes. I consider having unit tests in the ECM repo (and versioned with the
> scripts) essential.

Sure, that makes perfect sense. But we should not confuse the goodness
of such tests with the need to assure a broad swathe of code can be
reliably processed. The fact that this cannot be done in a manner
which is self-contained and thus automated within ECM is a fact of
life which the bulk tools deal with.

> Regarding my second point above, my next target is to add bindings to the
> KDE ki18n repo. That will require adding the ModuleCodeDb and MethodCodeDb
> to ECM. I'm working on autotest extensions for those.

Again, having self contained tests for that is fine. But my point is
that the ModuleCodeDb and MethodCodeDb code you need is already there
precisely because I was able to determine the need for it using the
bulk processing approach. Similarly, I know we *will* need TypeCodeDb
and friends in due course, so instead of slicing and dicing, why not
just pick up the changes in the way I am proposing? You are free to
write the self-contained unit tests for the parts you presently care
about!

>>>  I'm looking through the branches/commits in your github repo to see what
>>>  can
>>> be applied easily now. It looks like your
>>> KDE_fix_parameter_initialisation fixes kguiaddons for you, however, I can
>>> build kguiaddons with no problem without that patch. Can you
>>> double-check, and add a unit test in ECM if you can confirm this needs to
>>> be done?
>>
>> Please don't take stuff from commits/branches I've indicated are not
>> ready as I am actively rewriting them!
>
> I believe what I referred to above are part of your review requests.

Perhaps I was not sufficiently clear in
https://mail.kde.org/pipermail/kde-bindings/2017-January/008391.html.
Your commit c05dcfa4c4f39448323c4f52fbb534867a96747c takes a subset of
one of the commits in the branch that I consider a work-in-progress. I
have rewritten the history of that branch multiple times in the last
days, and I have no idea which of those you took. For clarity, I would
like to get '759 and '763 merged, and then I will queue up the other
changes for review.

>> I'll look and see if I can create a test case but as per my response
>> on the review, this is definitely a problem for me. I'll report back
>> via the review.
>
> Great, thanks!
>
>>> I also saw that you have a change to how the rules engine is populated
>>> (add_rules method). Could you make a commit for that based on master, and
>>> port the ECM test to use it?
>>
>> For me, to avoid creating a bunch of rebasing effort
>
> I think the best way to avoid rebasing effort is to get the missing pieces
> into ECM quickly (with tests), and preferably used by other frameworks
> repos. Then the only external piece is the bulk generator, right?

I agree.

>> As above, I've put it in a subdirectory to keep it out of the way, and
>> if needed, this can stay on a branch or something. But I do want to
>> get it into the same repo as the sip_compiler.py if at all possible.
>>
>> How does that sound?
>
> If it's in a different branch, how is that different from being in a
> different clone?

Having a single remote is nicer, but actually you are right and I'd
much prefer it all to be in one place.

Regards, Shaheed

> Thanks,
>
> Steve.