Open hildogjr opened 4 years ago
I do not have a lot of experience with Python, and I try to think in terms of objects.
However as far as I have seen, the code should be made in more "independent" parts and more internal APIs.
Some thoughts:
1-5 is the solution provided by the Kispace API, it group Octopart and other and make exactly this. It would be nice locally but, with my programmer experience in this specific area (I am basically a electronic programmer bach-end) it will be long-log time.
6 and 9 yes, the spreadsheet cold be some like 3 pages:
I fix, future fix, allow some kind of XLSX template. But to also achieve #317, #360 and #358, I need first #386 and #359 first.
7 is intended on #4 and #17, I am depending of https://kitspace.github.io/electro-grammar/ in Python, this would allow my also "automatically double check the BOM" (match value / footprints / ...) and warning the user at the spreadsheet.
This is also that I really like to attend. IMHO possible solve in two step: the back-end, as explained above and some front-end (maybe some tab at the GUI) for some setups (for example, you hare resistance and footprint, but need to set tolerance. For capacitor, capacitance and footprints, but need set minimum voltage or ...).
8 quick difficult even to discuss this now, I think. I could be also not understanding the full complexity of... At the past I just added LCSC distributor to make possible use JLCPCB assembly house.
10 yes, this is difficult. We had problem at past with the scrap method so we decide to move to APIs, which create another bunch of issues. Some already fix, I started a long time clean up work and moving on multiple APIs.
I think we need to move slow and consistence. Clean the house and organize the code to allow first the correct BOM data analysis #359 (some implementation as #266 and #328 could be affected by this change) and distribution organization #386.
@mdeweerd, are you using Windows OS? When installing, KiCost must ask you to install the GUI dependencies and create a desktop shortcut, also make a Eeschema integration (put KiCost direct at the Eeschema BOM list). This can be achieve by kicost --setup
(and undone by kicost unsetup
) but should be also add at the first installation.
I think is some wrong configuration mine at setup.py
.
When I created kicost --setup
I had the intention to "not explain the quick use of KiCost" (also because our manual is quick old...). It create the basic default fields on Eeschema and make some integration.
There is also this pending plan https://gitlab.com/kicad/code/kicad/-/issues/4091
I am on windows. I do not use the GUI, I prefer scripting.
I use kicost
under cygwin.
I also prefer on CLI (I made the GUI for users not good on CLI).
The installation procedure is not working yet...
At each installation KiCost was intended to:
Can you have a look at setup.py
? The issue is something related with the post_install_setup()
.
As @mdeweerd was said, could be interesting define some directive for medium-longe time development. I am calling for a discussion the author @devbisme / @xesscorp and others that could want to collaborate.
As far I had organized the code issues related to the GUI #361 and others aspects of the code.
IHMO we need:
distributors
folders already allowapi_*
orscrape_*
files to expand the allowed distributors. We could start by adding Digikey / Mouser APIs. It have to made simultaneous with #386;spreadsheet.py
for allow some kind of multiple manufacturer.plugins\kicad_netlist_reader.py
official file plugin for #359 and removelxml
dependence .