Open Immortalin opened 4 years ago
Not in the near future. To make the plugins to anything useful we'd either have to
With everything in one monolithic tree as we have it right now, making far-reaching changes is relatively easy and I don't want to give this up (yet).
For my opinion on autorouters, see https://horizon-eda.readthedocs.io/en/latest/non-goals.html
So if we do extend it we will have to fork?
If you really want to, go ahead, but I think this should be the last resort.
Talking about autorouters, I don't see much value implementing an autorouter in horizon itself. The right approach is to support importing/exporting the "standard" DSN/SES sessions to leverage existing autorouters. If someone comes up with a not-too-complex PR for this, I might merge it.
Re plugins: It really depends on what plugins should be able to do. If they should have the same capability as the app itself, they should be part of the app to simplify maintenance. To me at least, coming up with a useful architecture for plugins isn't worth the the effort right now as there are more important things to work on. Bringing another language into the game doesn't make things easier either.
A bit of clarification, I am not trying to push for an autorouter integration or anything. I don't have any particular opinion on that, my question is just about the recommended way for adding features in a modular manner. Because I think Horizon has a great UX and if it grows popular people are going to want more features like schematic editor SPICE support, advanced integration with other RF tooling, that sort of thing. It would not be feasible to put everything in the mainline tree unless you want a Linux Kernel style architecture which as you said has a high maintenance burden.
Having all plugins within the tree actually simplifies maintenance a lot as it makes refactoring or other far-reaching changes more easy and IDE features such as "find references" also include plugins.
Out-of-tree plugins would require having a somewhat stable API (and ABI?) and I don't think that's worth the effort yet.
Thinking about it, the current tool architecture is pretty close to what other people might call plugins as tools have a well-defined interaction boundary (IDocument
+ ImpInterface
) with the rest of the application.
BTW, spice is another non-goal: https://horizon-eda.readthedocs.io/en/latest/non-goals.html#simulation
What are you having in mind in terms of RF tooling? Impedance calculations are best left to other tools, but automating the creation of microstrip tapers and bends is definitely something I could envision living in the source tree.
Any plans for an official API? E.g. if I write an autorouter in Rust and want to be able to load it as a plugin.