atait/kicad-python

Pythonic wrapper API for KiCAD's pcbnew v5/6/7 used for action plugins, GUI scripting, and batch processing

kicad-python's Issues

[Suggestion] Remote/RPC Interface

Hey folks,

I was mulling alternative interface mechanisms given the breakdown of the pcbnew.so bindings on OSx, and was thinking about an RPC interface.

It seems like it might provide a more stable and agnostic mechanism to connect external programs to KiCAD, allow people to run programs from other environments even interactively with the GUI open and even from other languages if they liked.

I've used gRPC before - though it'd add a few deps (could be optional)
Other things would involve some more custom action, which is perhaps fine, though more effort.
There's XMLRPC as part of the standard lib that might be useful: https://docs.python.org/3/library/xmlrpc.html
There's another litany of RPC implementations; TinyRPC, RabbitMQ, and seemingly plenty of others.

Finally, Pyro makes it seem like we could even do something as straight-forward as exposing the pcbnew module/basic called methods Pyro5 expose

Very much spit-balling for the moment and sure I'm not the first to think of this - so curious to hear others' opinions!

Request for geometric tests

A recent addition to kigadgets was geohash. Non-identical boards have a <10^-80 or so chance of producing the same int. That was the missing piece needed for regression testing of behavior, not just test of import/run. The workflow introduced by lytest has been indispensable for my team in managing procedural layout codebases, so I added kigadgets compatibility in lytest v0.1.0.

"kicad-python/tests/geometry" has examples of this workflow.

Plz help with adding test cases!

Tests should represent multiple perspectives of the user base, including those who don't normally dev for kigadgets. These contributions would be super helpful 😎.

Comment below if you care deeply about particular features but aren't sure how to write the test, make a PR, etc. – we can prioritize writing that test.

If your project will depend on some kigadgets function and there is a test of that function here, then kigadgets effectively guarantees that it won't break that behavior for you (barring major version bump).

Also, now is a great time to start using the lytest/geohash workflow in your own project repos, even the private repos. This allows you to 1. Make behavioral stability guarantees to your users and 2. Immediately spot bugs in kigadgets pre-releases that would affect your work.

$ git checkout alpha.xxx  # in your kicad-python clone
$ pytest ../plugins/my-private-plugin/tests
[ FAIL ]
$ gh issue create --title "🖐️ it broke 😭" \
    --body "I am trying to ____. Reproduce the error with: <minimal breaking example>"

NB: That last line is just an example; I strongly recommend using the Github issue web interface

error message [swig/python detected a memory leak of type 'EDA_ANGLE *', no destructor found.]

This issue was created based on the discussion below,
In that discussion, it was suggested that the problem shown below was due to the kicad python API.
[https://github.com/yaqwsx/KiKit/discussions/673]
When I run the command provided by kikit to create a solder stencil, an error message is displayed.

command:
[kikit stencil createprinted --pcbthickness 1.6 --thickness 0.4 --framewidth 5.0 --ignore D1,R1 --frameclearance 0.3 --enlargeholes 0.1 ./3dprint_staincil_test.kicad_pcb ./staincil/]

error message:
[swig/python detected a memory leak of type 'EDA_ANGLE *', no destructor found.
swig/python detected a memory leak of type 'EDA_ANGLE *', no destructor found.]

The issue that was originally posted in the discussion, ``Stencil files are not generated correctly,'' has been resolved, but this error message still appears.

I have attached the pcb file that I used to verify the bug.
3dprint_staincil_test.zip

The environment used for verification was windows10, kicad 8.0.2, kikit1.5.1.

thank you.