New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] API plug-ins #509
Comments
Thanks by personally hit me, I didn't see this thread. Yes, I also had a plan to do that when I re-written some code at I did some work passing all general/template to the class at We should:
Since this new approach may need some change in files or new input arguments do KiCost, we may start a branch and I hope release a version when we merge to master... |
Hi @hildogjr The About:
I think this should be delegated to the plug-in. Currently On KiCost side I wrote a small plug-in wrapper that tries to import the plug-in module. If available gets enabled. Why try to keep it separated? Many reasons:
I agree we must create a mechanism to detect which methode to use when more than one plug-in can solve the same distributor. But I think this can be achieved using the priorities (already implemented) and one more detail: once a plug-in successfully solved a distributor it should be removed from the list. |
Agree with your observations. I made a quick look at the code. Apparently fails on I would rename |
There is the We could use it to the user define which APIs to use and them tokens. |
It works here:
But I think you are confusing the plug-in, I'm not using https://pypi.org/project/digikey-api/ but my own adaptation, look the link in the first post. I installed the plug-in using
And the module can be imported without problems:
And we have one test using it that is passing. Even for Python 2.7. |
Hi @hildogjr !
Ok, I renamed it this way. |
Not sure. If this is a plug-in the setup should be done during the plug-in installation. The current procedure is a little bit complex. |
Hi @hildogjr !
I implemented it. Now the Digi-Key API doesn't need to be manually enabled. If the plug-in is present the code will try to use it to solve "Digi-Key". If the plug-in is installed, but the initialization fails the code will print a warning. If the API solves the "Digi-Key" stuff then no other API will try to ask for "Digi-Key" information. In the test I'm enabling the use of the plug-in (providing a valid configuration) and then asking for Digi-Key only ( |
IMPORTANT!! While implementing this plug-in I realized that we should implement a cache for all the APIs. The cache for Digi-Key defaults to 24 hs TTL, you don't usually need to refresh prices more than once a day. Implementing it for KitSpace will solve saturation problems without needing to disable the prices by default. |
I still have to try with Digikey account. Cache will be nice, mainly because we return to the BOM generation process when release that some part is missing. This need appeared some time ago in other thread but, at the time, I didn't think I good way to implement it (Also because, in the model that KiCost is taking, with multiple APIs, this cache should be a top level caching query of all the APIs/scrape/...). We also should think about the configurations/parameters of KiCost. I think the command line is taking to much options, making difficult to new users. |
I'm not sure about implementing the cache at top-level. I think each API should implement it. I agree we could have some common code to avoid repetition. |
Yes, and I don't think KiCost should centralize the complexity of configuring each plug-in. The Digi-Key plug-in will have some configuration details that aren't currently part of KiCost. I.e. country where you place the order, or destination country. And these values doesn't have to be the same for each distributor. I think the plug-in should allow configuring it in a file. May be we could add some GUI for the file, but this is very plug-in specific. |
I am in favor of caching, this may also depend on the API's caching rules/agreement. (For geolocations, Google does not allow caches older than 30 days). I think caching can be longer than 1 day by default (maybe 1 week). Availability changes faster than prices (especially nowadays), so close to ordering one may want to get the most current stock states. I'ld suggest the default to be about one week and to allow for an option like '--cache-age=0.25' to seek new values when they are older than 6 hours or non-existing. Personnally I have these steps:
This makes me think of another feature: currently kicost does not allow me to check the descriptions from the distributors vs. my own. For instance, I expect 10k, and due to a copy/paste the manufacturer code is for 22k - kicost does not help me detect this unless I click on the distributor links. |
@set-soft , should it be viable a single @mdeweerd, a also did this in a package error once. I would like to use #4 in this sense, by using some "electric grammar interpreter" (https://kitspace.github.io/electro-grammar/) to valid value and footprint, marking the spreadsheet is not match. |
Electrogrammar is interesting, but having the possibility to see the description of one of the distributors as text next to the design file description is already helpful (not always, but when option is activated). I tried the following on Electrogrammar: "r0603 10uF 0.1% 100V" . I do not know if it indicates the inconsistency in its API. I also tried "0603 10uF 0.1% 100V low esr". It works pretty well and could improve the detection of differences. |
This can be done. Currently Linux apps stores the configurations in If we want to centralize it we should also make the plug-ins able to use For other OSs we must determine which directory is suitable. I saw a lot of Windows applications using BTW: wxWidgets uses some particular mechanism, and the GUI is currently using it, and with a very archaic format (INI files). |
Regarding configurations in Using |
Related to this @mdeweerd : In KiBot I'm generating an extra worksheet containing the "Specs" information, is customizable, here is an example: |
This could be add as additional spreadsheet-page or other KiCost output file... I just have to define how. About the configuration file, I tend to choose some unique About the cache, K-inTree or other Python package could be used to make it more transparent to KiCost code? |
Take a look at the cache mechanism I'm using, is trivial, no need to add extra dependencies. |
A very small patch: abced19 allows this: I know this isn't the best, but is a very small change. |
A better implementation: 505ae8d Which is what the code wanted to do, but lacked the data |
And now 3880660 Is currently disabled and only enabled by modifying the code, but will be available when an option is added. |
Nice! |
Not sure about it because:
Don't get me wrong, I'm not saying this is a bad idea, just that I won't implement it soon. Perhaps @hildogjr wants to implement it. |
The idea is to generate it only for verification, not for final bom creation.
Ok, I guess I can also hide the other columns so that the two interesting ones are still next to each other ;-). |
@hildogjr : replying to myself ;-)
I implemented it in The cache files are stored in Currently only APIs take advantage of the configuration file. And to be honest just Please take a look at it and give me your opinion. Next will be to add some cache support for BTW: Now |
More news:
|
After a long time:
@hildogjr : do you think is time to merge it and debug? |
Sorry be the delay. I am attempting a new job position, I will be quite busy next months. The branch have passed the automatic tests. If you can confirm, I think will be fine to merge and release (mark the Gittag "vX.X"). |
Ok, I added the TME API and will revisit the Digi-Key API before the merge. |
I merged, but didn't release yet. I would like to see reports from people using it. The code passes all tests for all Python versions. The Digi-Key plug-in now is available from PyPi and is a regular dependency. I also tested that KiCost runs without the plugin installed. But again, I would like to see success reports before releasing it. |
These APIs are in use since 1.1.8 and looks like they are in use because we got 3 reports for problems using Mouser API for people using languages other than english. |
Confirming that Digikey, Mouser, Farnell and TME APIs are working in our case. Thanks for your effort! |
We all know that KiCost is saturating KitSpace gateway to Octopart. In order to reduce its load I would like to introduce alternative mechanisms. The most important distributors provides some kind of API to do stock queries. I personally use Digi-Key so the first API I'm trying is this.
I created a branch called
api_ext_plugin
(https://github.com/hildogjr/KiCost/tree/api_ext_plugin). In this branch I'm starting to play with the concept.The first plug-in is here: Digi-Key plug-in
The setup is a little bit complex, but doing it you get 1000 queries a day for free (slow queries by the way).
Any comments? Anybody can help to test it?
The text was updated successfully, but these errors were encountered: