SebastianSchildt
commented
9 months ago Like the idea, I guess @adobekan would agree, as we have discussed a similar idea.
One main advantage would also be that you can "pip install " vss-tools, import sutff and create your custom exporter without touching COVESA upstream code. Today users are basically "forced" to fork, and I have seen such internals forks flying/rotting around. Resistance to pick up new features upstream would likely be lower, if you just need to upgrade a dependency
erikbosch
This is an idea I have for restructuring of vss-tools. Ass of today we have vspec2x.py as main entry point. It explicitly lists all exporters and import all of them as well. This has some drawbacks:
vspec2x.pyAn alternative solution would be to instead have
vspec2xas an abstract tool that require an exporter as input. That would make it easier to create you own proprietary tool/exporter, you do not need to modifyvspec2x.py, instead you could just create you own exporter and give it as an argument when calling vspec2x. This PR shows how that could look like for vspec2json. The filevspec2x_abstract.pyis intended to replacevspec2x.pyIf we go this path we could as a second step consider refactoring our vss-tools PyPI package so that exporters with "heavy" dependencies (big size, or dependencies that only are supported on a limited set of platforms, or dependencies to less user friendly licenses) are put in a separate PyPI package. A possible example could be graphql. We could also possibly add generic exporter functionality/hooks so that exporters can add or control additional semantic checks or processing steps if needed. A typical example could be the recent discussion to expand signal tree based on allowed units. Maybe that is a feature that is possible or even mandatory for one exporter, but totally useless for others.