Discussion implementation v2

[hildogjr]

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:

1. Organized the file open modules #359;
2. More APIs modules, as far I change code, the distributors folders already allow api_* or scrape_* files to expand the allowed distributors. We could start by adding Digikey / Mouser APIs. It have to made simultaneous with #386;
3. Could be designed a new spreadsheet.py for allow some kind of multiple manufacturer.
4. Use plugins\kicad_netlist_reader.py official file plugin for #359 and remove lxml dependence .

[mdeweerd]

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. An internal database could be used where each component from a manufacturer has an unlimited possibility of properties.
2. That database is filled by readers. A timestamp on the data allows to indicate for how much time the data is valid (some dataproviders does not want us to store data locally for too long). The access to the database would be implemented using an API. Readers and writers should call methods to add or get information about a component, not modify the data directly.
3. The database could also keep other information (licence keys, etc). As the database is accessed through an API, the implementation could vary. To start it could be internal arrays, then it could become sqlite3, and later a central mariadb or whatever.
4. The database would avoid scraping component information that that was already scraped before.
5. The design information does not need to be in the database.
6. There would be several writers. They could be implemented using a Builder Design Pattern. There could be more options for Excel files. One of the EMS companies I work with use a single line per component - inside the cells they have one line for each alternative.
7. It would be nice to add a function where components would be selected based on the component type and value - for instance for resistors. The matching list could be dependent on the PCBA manufacturer (some provide lists of resistors and capacitors that they have in stock).
8. It would be nice to have configuration files that would represent PCBA manufacturer settings (list of distributors that they work with, components that they have in stock).
9. The spreadsheets would be more complex and capable of choosing the best component amongst several alternatives for a single reference. We may need to add a sheet to do the computation and only show the result on the main sheet.
10. The reader/write APIs would need to be stable.

[hildogjr]

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:

1. This selection parts;
2. The actual with the chosen one ;
3. Some compilation with costs and field to add tax and etc (useful here for customhouse importation).

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.

[hildogjr]

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

[mdeweerd]

I am on windows. I do not use the GUI, I prefer scripting. I use kicost under cygwin.

[hildogjr]

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:

1. Prompt: Do want to install the GUI requirement packages? (Y/n)
2. Integrate with Eeschema (put it on BOM list).

Can you have a look at setup.py? The issue is something related with the post_install_setup().