Closed djcopley closed 8 months ago
If this is something that the maintainers of fusesoc feel is a worthwhile change, I'd be happy to submit an implementation for review.
One step ahead of you :) This has been available for about a year https://edalize.readthedocs.io/en/latest/dev/extend.html
Yep, sure is! Sorry for the dup :P
Summary
Fusesoc currently relies on the edalize package for its edatools, a system that works well for the supported edatool set. However, it is unrealistic to expect a first-party library to develop and maintain plugins for every potential edatool. Presently, there is no straightforward method for community members to create and share edatools, aside from submitting a pull request and awaiting approval.
Proposal
I propose the implementation of an extendable plugin interface that empowers third parties to develop edatool plugins. These new plugins would be installable via pip, making distribution feasible through various pip-supported mechanisms such as wheels, PyPI, git, etc. This could significantly facilitate the creation of unique toolchains, especially for proprietary users of fusesoc. Companies could craft edatool plugins for customized tooling and effortlessly distribute them internally.
Technical Details
The suggested approach involves restructuring the fusesoc and edalize packages so that the Edatool "interface" is disseminated by the fusesoc package. Edalize will still exist as a package housing first-party Edatool plugins. Python provides excellent tooling to facilitate this style of plugin distribution.
I propose the utilization of Python entrypoints to discover and register third-party plugins. An exemplary open-source project employing this method is OctoPrint, showcasing the effectiveness of entrypoints for pip-installable features.
Future Efforts
This approach could seamlessly extend to providers in the future. For instance, a third party might create and distribute an internal Git service provider (e.g., GitLab or a similar platform).