As an open source project is there enough interest that enough developers would band together and just write code to scrape individual distributors and then aggregate?
1 Like
I think BOM scraping should be open as well- in the sense that info from user’s part “properties” need only be processed and presented in a manner similar to kicost. No need to go overboard about linking with any particular external plugin or site that forces user to compromise his “open” approach…Here “user” knows best what he/she is doing…If they need extra help, it is much better to post here & thousand willing partners will do so.
Now, it is perfectly ok to develop a plugin that works with KiCAD & is based upon honor system of contributions.
This way the integrity of the entire Open approach is maintained and let blossom.
Yes, @SembazuruCDE just 2 active developers, the author @debisme and I.
My expertise is not in web, reason way I was advancing in logic / validation and the different currency implementation.
The scrape module create the big issue when the distributors web page start considere us as an robot (that is true).
Now KiCost is having issues with the GUI in Windows that, even if I finish the new API migration, will delay the release.
1 Like
The new distributors module
accept api_*.py, scrape_*.py and dist_local_*.py. I hope that in the future KiCost will be not dependent of a specific API.
I would state that "good luck with Altium " then!
I do not see how they can beat any manufacturer’s info!
Now can they “buy” out kicost?
nah.
Many worthy .py coders can hack it up…besides, making BOM may become an integral part of KICAD…I am hoping.
There are 1000s competing sch/layout product developers…quite expensive & each has a way to build BOM, including obd++…most elegant & simple is KiCAD…
then what happens?
On top, I would suspect any info from any source other than the original IC/chip/ part whatever…vendor for my use! Neither I would encourage dissemination of such info in our organization.
This has to do with the integrity of the info- nothing against any vendor trying to make a buck on free info.
Finally, if I were a vendor of a part: I would object to a third party making my customer pay for inforthat she would get , uninhibited, free!
It was a surprise to me that Ocopart existed inside kicost…been in the industry 40 yrs …never felt the need for such a service.
It is like buying parts from a third party : unauthorized – would you put that part in your system?
We cannot
KiCost was using Octopart. The only relationship is KiCad is one of many clients of Octopart’s information service.
I’ve directly used Octopart before. It took a lot of the hard work of deciding which vendor to buy parts for price conscious small-run projects. It actually allowed me to decide for a project which parts to buy from Digikey, which parts from Mouser, and which parts from Newark. Not like for my quantities I could buy direct from Vishay or TI…
Sembazuru
Although you make good points, I would say that paying shipping will eat out little differences in pricing here & there.
#2, online buys are very competitive, if not lower than, distis. You can buy 1, sample many( which no one else will ever give you), buy 10 or 100.or 10k!
So not sure how any consolidator will help really.
Much like “travel agents”…gone. You can buy lower priced tickets online…on any airline from anywhere on this Planet.
Pl note this will be my last post on this matter.
KiCost started use Octopart API because we (the author and I) wasn’t able to fix all the scrape module on time for new releases. We was using data from 7 distributors, so it was 7 different scrape modules. Each time that one change the HTML page or coded a new java script for get robots out we had to re-code the correspondent file, it became unproductive for the tool (and just 2 maintenance).
About use direct data for large quantity, I don’t now how to start. The only experience that I had in this case was sent a form for a quote, it wasn’t direct in the web site.
2 Likes
Let me see what we can do to address the issues.
But your work is highly appreciated.
We just have to make sure it can be used without getting tied up with 1 company trying to resell some service when no such service is required.
robin
Hildogjr
Good news is that in a Linux machine, kicost works just as advertised. But not so in w10
we will find out how & why this week.
you did a good job for the plugin. Very useful
-robin
Thanks Robin by the report. I am in my PhD finals now, soon I will return the development.
As far I debugged, it is related with the babel package that I am using now to provide the different currency symbols in the spreadsheet, for currency conversion possibility (and future GUI translation if some one want to).
Linux appear to have already defined some system LANGUAGE variable that is not in Windows. I don’t know if it a Python babel package issue or just some definition that I have to add in Windows though the setup.py.
Some user told me about this workaround:
1 Like
Some alpha code with the new API in the main branch of our GIT https://github.com/xesscorp/KiCost
we appreciate that users send patches to fix the remain issues.
All base functionalities are migrated to the new API.
The developer team wait for users contributions and validation to fix some issues before release it in pip.
Will the newest version of KiCost, to be released on pip, as described above, use Octopart now? If yes, will the user need a paid subscription to Octopart to use their “service?”
Thank you for your hard work!
KiCost will use the KitSpace-PartInfo API. @kasbah can give more information about the financial support.
The actual version of KiCost in pip use Octopart, the next (in beta validation) keep the Octopart module as compatibility and for large use, implement the PartInfo and even allow multiple module (I re-wrote portion of the code to allow this, allowing future Digikey specific module, for example).
But this version will just be release when “someone” help me with the issues in the milestone (https://github.com/xesscorp/KiCost/milestone/1). Particularly with the Windows and GUI related issues, because I have not how to debug Windows and GUI is not really my expertise.
1 Like
If someone here have some Python skill (in Windows or GUI using wxPython), it will really help this release and I can concentrate in next features that are the roadmap https://github.com/xesscorp/KiCost/milestone/2. Particularly the #17.
I have mentioned before, there is a chance we can do something about it…
But for now, it is clear the kicost script works very well in a Linux system.So it needs some edits for W10 …there was not a quick fix when my son tried here in our work place 10 days ago so we deferred it for a next time slot…
Last KiCost code is working on Windows and in both Python2/3.
1 Like
Guys, KiCost is close to a new release with new features and fix problems.
One interesting feature is the kicost --setup (executed on installation) and kicost --unsetup commands that set and unset configuration like shortcut and Eeschema integration (this is though to not IT/python expert users):
The feature was tested on Linux, so I need you friends to test on Windows and Mac-OS:
- Check if the integration is done on installation;
- Execute
kicost --unsetupand see if the integration/shortcut is removed; - Execute
kicost --setupand see if the integration/shortcut is re-made.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.