Extending Cadquery

What are the best ways to extend cadquery?

This page lists some topics/thoughts to facilitate discussion. The items are numbered for easy reference in conversation

The Questions

1. How do we decide which things go into core, and which ones do not?
2. What are the preferred ways to extend CQ?
3. what ground rules should be followed for accepting contributions for core code?
4. Does the structure of CQ itself allow for the best answers to these?
5. What plugin types/structure is right? And how opinionated should we be?

Thoughts

6. We have public contrib repository, but many have decided also to use external libraries
7. We do have a standard proposal on how to use plugins, which use monkey patching
8. There does appear to be more standard ways to support plugins, such as here: https://packaging.python.org/en/latest/guides/creating-and-discovering-plugins/
9. vertical plugins like django? CQ does not have a rich set of plugin interfaces. How do people feel about extensive plugins like django uses, where a plugin can contribute functionality at lots of layers?
10. some really great work uses plugins, some doesnt cq-kit and cq-warehouse how should we help these projects?
11. if we want to make it easy for users, and we want to support extensions that are separate projects, should we have a curated list of third party repos?
12. what would we say is the very core of CQ, and what things would we say are NOT core?
13. CQ could become like Java Spring In my day job, i work a lot in the Java ecosystem. If you know Java, you know Spring, which was once a small, tidy library. Then people kept adding great code. It was useful! But then spring got really really big. And it became hard to choose versions, because there were so many included modules. Eventually, spring went hyper-modular, and kept only the very core in core, splitting out all of the modules. this made it easier to tune which bits you want. but introduced another problem of trying to find which modules are compatible with what

Motivating Issues

14. One discussion revolved around extended export functionality. One argument is that cq should not reach far above OCP. another argument would allow that, because it would be beneficial to lots of people
15. One feature that was clearly within scope of core, 'thicken', was authored but ultimately not included in core because of disagreements about the implementation. this begs the question: what should the ground rules be? Are different coding styles allowed, etc.

Ideas

16. What do people think about making plugins more django like?
17. If so, how would we go about finding/listing said items, so people know where they are? In the end, there has to be a list somewhere.
18. How would we manage matching which versions of plugins use which CQ versions
19. How would we allow plugin authors to export multiple versions of a plugin for alpha/beta/stable.