I completely agree with qu1ck’s post, and as a plugin developer, I also concur with yaqwsx sentiment.
I’d rather see eeschema and project manager get provisional python API. The issue of fluid python API in pcbnew can currently be successfully tackled with unit/integration test, so I am not really feeling the need for newer/better python API in pcbnew.
Small production runs of multi-PCB products (ie. mainboard + power, sensor, or battery board) where you want to assemble the entire thing with 1 stencil and then break the boards after the fact rather than stenciling multiple PCBs per project.
Squeezing in small adapters and test boards into the unused space of complex large shape boards to save money.
Ganging multiples of the same PCB for OpenPNP assembly.
Debug headers or TAG-Connect / flashing footprints that are too big for the final project so are on a side area and broken off prior to final assembly.
Lots of reasons for home panelizing.
1 Like
No, it can’t be fixed with unit tests unless you want KiCad development to grind a complete halt indefinitely. The problem with the SWIG api is because its autogenerated from code. We keep changing the code because we have 20 years of legacy to constantly refactor and throw out and we’ve ramped up those efforts recently (I just eliminated the last horrible shared crutch of a file managing coordinate scale across programs via #ifdefs and link-time behavior). Trying to write unit tests against the current state of SWIG means we now have to stop all development as we can’t change anything or else the auto generated code does.
I think MitjaN was referring to tests in the plugins that test if the plugin still works with API. Not KiCAD tests for API.
1 Like
Yeah, I was referring to test that I as a plugin developer run, to spot any changes in current python API. Thus instability of the python API is not a big problem for me (and to be fair since 5.1.x python API changes are rare).
What does the current python API implementation mean for the main developers I don’t really know, but I trust you fully that you know how to proceed with development. My comment should be viewed as only one data point on how to proceed with python API development. Obviously if other aspects have more weight (code stability, ease of development, …) then they should drive the development. I am happy (if somewhat inpatient) to wait.
Just to add, I will repeat my wish that I have expressed multiple times: I am also happy to wait (thought impatiently), but I would appreciate clear and consistent communication from the developers. We only get rumors/flashes in a forum, IRC, and issues that “the API is near! Just wait for the next release”. If there is no API happening, we would like to know. If something is happening, we would like to know.
I would really like to help with the API; I have asked about the status multiple times on the developers’ list. I offer my programming time to get the API done. However, I have never received an answer - even a negative one such that no help is wanted. I even asked on Fosdem, and I got the answer, “we will let you know in a few weeks.” With no follow-up.
API is a big feature set, and I understood that the developers have some ideas on what it should look like. But we don’t know it. So I don’t want to invest time in something that wouldn’t be accepted.
I understand that the developers have no formal obligations to the community as they are not doing any contractor work for us. But I think the lack of communication is hurting the community and stopping KiCAD from being even more awesome.
I would like to know if there is anything we, as (a power user) community, can do to help KiCAD get API. Should we crowdfund money for contractor work? When I donate to KiCAD (I donate 10-15 % of my KiCAD-related earnings to the project), can I specify that the money should go to API development?
PS: Based on the fact that just in under 36 hours, this topic has many answer, I think this is sign that API is “hot” topic in the community.
7 Likes
I have had a very similar experience. I was in a position to put a decent chunk of time into helping implement the API and when I asked on the dev board I got brushed off with questions that were unanswerable due to the lack of public information, like which bit do you want to work on? When I replied saying wherever needs more attention I didn’t get a follow up response, even when I followed up later.
I couldn’t find any decent information on Gitlab about the api. I would totally believe the API is not happening. The development is definitely not out in the open.
Disclaimer: I do not wish to overshadow the tremendous feature set and quality of life improvements of KiCad 7.0. The team have worked hard independently and together to build a mature EDA solution whose new database features, extended eeschema fields, and other forward-looking features will increase adoption and offer a compelling alternative to commercial options. I am not a C++ programmer but am experienced in PHP, Perl, and other scripting languages. I have genuine interest in developing Eeschema plugins. I am making this post in good faith, not to complain.
APIs are hard. And it seems clear, reading the Gitlab report and having witnessed the Eeschema API Rewrite shift from “imminent” to “dead” twice in two years, that we are at an impasse.
In my experience, there are two types of API. Incomplete ones and unshipped ones. The desire to make a comprehensive API and to expose the entire codebase to users is at odds with the effort involved and the potential increased maintenance as internal systems must now present consistency where previously they could be ripped out and rewritten with little fear.
To even define an API and break it up into discrete manageable development chunks would require a level of executive ownership and commitment that is just “not fun” and likely beyond the desire of any team member. KiCad is developed by a volunteer army who, by and large, contribute things they want the software to have. Any feature they imagine an API would enable the creation of could simply be written and contributed into the core. An API is a hell of a lot of work just to sit back and wait for the 3rd party community to materialize.
I can’t help but notice the last two posts are from individuals above who volunteered to contribute and were met with a noncommittal “the beast is over there” finger wag followed by silence. Is it time for an API working group to define a scope, set incremental goals, and start building a bit at a time rather than facing down an elephant?
6 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.