openscopeproject/InteractiveHtmlBom

Saved settings not remembering empty 'Whitelisted' board variant

myamigo opened this issue · 4 comments

I use a variant field in my design called "Config" and I am generating the iBOM variants by exception so I should always include all components with nothing in the "Config" field. Then I include Whitelisted +VARiants and exclude Blacklisted -VARiants.

I do this typically as follows:
image

If I save what you see here to the settings file (ibom.config.ini) and restart the plug-in the Whitelisted blank line will incorrectly appear unchecked. My workaround for now is to just check the blank line when I start the script.

I tried to use the script from the console but I have dependency issues that are not making that easy so I'd rather work with the settings file.

qu1ck commented

Empty string handling fix is in, will be in next release. It likely will be a while so if you want to get it early get latest from github and use manual installation instructions from wiki.

Also FYI what you are doing is redundant, there is never a reason to use both whitelist and blacklist simultaneously.
When blacklist is set a component with variant in blacklist will not be in bom. When whitelist is set, a component that is not in whitelist also will not be in bom.

@qu1ck thanks for the, well... quick fix.

I am using KiBOM to manage BOM variants. +VAR will include the item if VAR is specified as a CLI arg and -VAR will exclude it. This works very well.

For example...
image
This will install jumpers JP5 & JP6 and leave JP4 unpopulated if if I call KiBoM as follows...
python "KiBOM_CLI.py" "%I" "%O.html" --variant VAR

... and the opposite if I do not include the VAR variant as a CLI arg...
python "KiBOM_CLI.py" "%I" "%O.html"

I handle this now by Whitelisting +VAR components and Blacklisting the -VAR ones if I want to include the ISB_Local page. You can see how I have to use both the Whitelist and Blacklist together. I also have more complex VARiant assignments so, for example, I might have the Config field set to +VAR,-PRD. This would include the component if VAR is an arg and PRD is not. Complex assignments like this require more entries in the black and white lists.

A really cool enhancement to your plugin would be if it scanned the variant field and extracted a unique, short list of VARiants identified by dropping the + and - prefixes and add them to a different list. Then when you traverse the components and check the variant fields you can include the parts that have +VAR in the field and exclude the ones with -VAR. If you extracted all unique flags from the variant fields then for my example you would have a list of 2 items... [VAR, PRD]. This would make handling complex variants much easier.

Another useful addition would be to include the selected variant flags in the output, perhaps after the revision. I can create issues for these 2 ideas if you'd like me to do that.

I use your plugin and KiBOM to great effect. They would work even better if this was possible :-)

Hi @myamigo !

Just my 2 cents KiBot can handle KiBoM variants and pass them to iBoM. KiBot is native for Linux (locally executed or using CI/CD docker images), and can be installed on Windows using WSL2.

As a plus the internal BoM is a superset of KiBoM, so you can use old KiBoM configs or migrate to the internal BoM.

It also supports KiCost (including its variants system, or applying KiBoM variants).

Of course this is not as simple as GUI tools, but you can use KiBoM variants and get them integrated with the other tools.

qu1ck commented

I handle this now by Whitelisting +VAR components and Blacklisting the -VAR ones if I want to include the ISB_Local page. You can see how I have to use both the Whitelist and Blacklist together.

No, it's still redundant. In that case whitelisting +VAR is enough because as long as whitelist is not empty, everything that is NOT in whitelist is effectively in blacklist anyway. This is different from KiBom logic, ibom does not treat variant field as a list of flags, it's just a string.

A really cool enhancement to your plugin would be if it scanned the variant field and extracted a unique, short list of VARiants identified by dropping the + and - prefixes and add them to a different list. Then when you traverse the components and check the variant fields you can include the parts that have +VAR in the field and exclude the ones with -VAR. If you extracted all unique flags from the variant fields then for my example you would have a list of 2 items... [VAR, PRD]. This would make handling complex variants much easier.

Different bom tools have different variant logic and there is no one right way to do it. Ibom's current system is simple, flexible and compatible with every other system. It can accomplish what you want, albeit with more checkboxes to tick, so I plan to stick to it.