kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <majopela@xxxxxxxxxx>]

A transition time as wayne suggests could be a reasonable thing, with
enough time,
and a proper deprecation notice users would be able to transition into a new API
(please consider looking at [1], I spent quite a long time modeling that based
on the initial work of Piers Titus van der Torren)

Let me add some notes to the discussion as author of the bindings (the
guilty one ;-) ):

  At the time when I started working on the bindings, I was only able to
recognise two options that were suitable for us, we either a) built our own
bindings manually with C, or b) we had swig, which at that time, was the
same solution that wxWidgets was using. I remember I examined other
automated binding solutions, but having wxWidgets compatibility was a
strong point, it all got discussed in the community and we weighted our
development capacity.

  Also, we had the future eventual change to python3, that may be easier
with an automated tool (I agree, I'm very optimistic sometimes)

  So we picked that path, and I made an initial version, eventually we
got wxpython support contributed, the wx console for python, etc...
around that time my contributions decreased / disappeared because I
had two wonderful daughters (one after another) and I'm still trying to
recover from that.

Around that time, we also started to recognise two things:

   a) The bindings, even if limited in scope to some objects, were troublesome
because any refactor on the objects could break external users of the API.
IMO, that's something the users must understand and accept that eventual
breaking changes will happen to the API.

   b) The bindings didn't allow users to access objects in a python-like and
easy way, all was cluttered with the creation of objects which had to be
passed around.

   c) The documentation was for the C++ side, not for Python.


So, we weighted in again the possibility of writing native bindings, but we
realised that it was easier to layer on top of swig, and do all the
heavy-lifting
of providing a consistent API in python [1].


So we had:

    kicad objects <--- swig API bindings <--- kicad-python <---- user

If any breaking change happens in kicad objects, the kicad-python wrapper
is updated and the user doesn't need to change anything.

While the old users still had access to the swig bindings (knowing that
those could eventually break), they had the chance to pick up something
better.

Some examples here:

Docs: http://ci.kicad-pcb.org/view/KiCad's%20pythonic%20python%20API/job/kicad-python/ws/doc/build/html/index.html

https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py

https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_board.py


Now, I'm not an active developer (for now) but, I know that you'll take wise
decisions, of course feel free to reuse that -and ask me anything you need-,
keep building on swig, or not and take any other direction. I will be happy
to see anyone stepping in to handle all this work and provide a consistent,
easy to use API for KiCad.


Best regards,
Miguel Ángel.









On Fri, Sep 16, 2016 at 8:30 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> On 9/16/2016 2:13 PM, Michael Steinberg wrote:
>> Hello Wayne,
>>
>>> Yet.  I'm sure they are going to have to implement it at some point.
>>> You can always write your own swig wrapper something like this:
>>> http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
>>>
>> They had 5+ years to add support, they didn't. So I wouldn't count on it.
>>> As some of you may or may not know, the new wxpython project phoenix is
>>> using sip instead of swig so that in and of itself may put us in a
>>> position where we have to change to sip.  I would rather wait and see
>>> what shakes out with the new wxpython implementation rather than head
>>> down a path that only has to be changed yet again.
>> And another break, will we support SWIG, SIP and an interop layer?
>>>> With this message I want to ask what is the common view whether it is
>>>> okay to have SWIG thumbscrew the project's source code, considering
>>>> there are alternative generators, and generatorless libraries like
>>>> pybind11. Of those alternatives I would *personally* prefer the latter,
>>>> as it is no black box and the binding generation is part of the normal
>>>> c++ source code.
>>> Honestly, changing scripting language generators does not thrill me at
>>> this point in the project.  It would most likely break all of the python
>>> scripting work done thus far which would create a lot backlash.
>> It will only get worse as time is passing by building upon the current
>> state.
>>
>> I think we need
>> 1) a specified python API
>> 2) adapters that match the specified API to the source code
>> 3) Helpers to generate the necessary binding from the API adapters. This
>> can be done with the aid of libraries or manually.
>>
>> It seems none of that is currently available, the current unspecified
>> API holds the source code tight, with a generator that hinders
>> refactoring to modern c++ style. So we only lose on both sides.
>>
>> Michael
>>
>
> The only way I could get behind this if it's implemented separately from
> and in addition to the current swig wrappers.  This would preserve the
> investment folks have in their existing python scripts and they could
> decide which bindings they prefer.  Forcing this kind of change on users
> generally doesn't end well.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp