search

horizon-eda / horizon

Horizon is a free EDA package
https://horizon-eda.org/
GNU General Public License v3.0
1.12k stars 83 forks source link

Plugins/Extensions #385

Open Immortalin opened 4 years ago

Immortalin commented 4 years ago

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.

carrotIndustries commented 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

Immortalin commented 4 years ago

So if we do extend it we will have to fork?

carrotIndustries commented 4 years ago

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.

Immortalin commented 4 years ago

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.

carrotIndustries commented 4 years ago

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.