InteractiveHtmlBom
InteractiveHtmlBom copied to clipboard
openscopeproject
Consider making InteractiveHtmlBom a package
Would you consider packaging InteractiveHtmlBom so that it can be easily installed and imported as a module in an external script/tool?
The use case that I'm currently working on is a tool which integrates with BOMIST (electronics BOM and inventory management tool) via its swagger REST API in order to inject proper/sanitized part number, value, package, part storage location, etc. into the generic JSON pcbdata object that I get out of Eagle/Fusion - after which I want to push the updated JSON through InteractiveHtmlBom automatically, without the user having to separately invoke it via CLI.
I experimented with this and it was fairly straightforward to get it working at a basic level (add setup.py, pyproject.toml, etc) but I'm not confident that I know the "right" way to architect it so that it fits cleanly into the ibom architecture - especially if it should be generalized to support any workflows other than the generic JSON one with which I'm most familiar.
I'm assuming by package you mean pip/setuptools package. Yeah, I can look into that. If you share setup.py and any other files you have, that will help.
I pushed my experimental branch: https://github.com/Funkenjaeger/InteractiveHtmlBom/tree/package It's not much more than a proof of concept, but it did work. I set it up to just push arguments through the existing argparse so I didn't have to reinvent the wheel on any of that, but I'm sure there's a cleaner way to do the whole thing.
For me personally, you can consider this request OBE.
I refactored my project repo to bring ibom in as a git submodule, so I'm able to do what I need without needing to install ibom as a package or modify ibom in any way.
I still think it would be helpful to add a requirements.txt for ibom, to simplify initial environment setup for non-Kicad users, even if you don't elect to set it up as a pip/setuptools package.
Can I help with the packaging? I'm a fan of following using the cookiecutter format: https://github.com/audreyfeldroy/cookiecutter-pypackage
I can image this creating confusion with the plugin installation though.
Last I looked into this I didn't like the templates because they did a lot of stuff that is not needed here. I don't want to discourage you from contributing but this will likely take me as much time to review as it will take to setup from scratch myself because majority of the time will be understanding packaging and all the options.
If I remember right, last time I looked into this I stopped because I couldn't decide whether to make wxpython a hard pip dependency because it is not needed for cli usage and can mess with system wxpython installs on linux.
Probably right call is to not make it a dependency but gracefully detect lacking wxpython if GUI dialog is requested.
Okay, any other notes? There is of course how the KiBot guys have gone. Is this not a direction you want to go or have they just not been submitting pull requests?
Just my 2 cents, the goal of the Debian package for InteractiveHtmlBom is to make it easier to create, and maintain, KiBot docker images and installations. We never submitted patches about packaging, most of our contributions to InteractiveHtmlBom were oriented to make the tool "system wide friendly", something needed to create packages.
Why not contributing packaging stuff? Simple: because this is out of the InteractiveHtmlBom scope, this is the case for most tools packaged for Debian and derivatives, the packaging stuff is kept outside the upstream repo. This is because the author/maintainer doesn't know the details for packaging the tool.
As InteractiveHtmlBom is mostly used as a KiCad plugin a "package" for the KiCad Plugin Content Manager is enough for its goal. That said: having it available at PyPi and usable as a module could help a lot of people.
Of course, this is just my opinion.
RELEASE THE KRAKEN... umm I mean package https://pypi.org/project/InteractiveHtmlBom/