Different script styles (old scripts to update to new style) about kicad-footprint-generator HOT 1 OPEN

I would consider #55 as a basis before doing any rewrite.

Some thoughts, which are quite a bit of work, but I would consider necessary for a powerful script system in the future:

• Develop an official ModArparse successor, based on our experience and the ideas of @poeschlr
  • use advanced features of yaml like data typing/custom data types (things like 1+-0.05mm without hacks) and scheme definitions
  • general naming and structure convention including how files should be formatted (linter)
• move to the official KiCad codebase. I already started with an abstraction layer: https://github.com/pointhi/kicad-python
  • this would contain a high-level abstraction of the KiCad datatypes as well as helper functions on top of them (like our specialized nodes)
  • KicadModTree would get an additional KiCad backend to help transition
• make an official scripting repository
  • scripts would be required to follow strict rules like flake8 and basic structuring
  • one command to make them all. The structure would be a bit challenging due to reuse of scripts in different libraries but a worthwhile goal

What would we get?

A reusable set of scripts. Which means one script which is capable of building custom footprints, as well as whole libraries (make/cmake support) which also supports the Footprint Wizard of KiCad out of the box. Think about it: people would only need to edit/reuse a config file and press make. And their customized library appears. When a part is missing you could start the footprint wizard and interactively create a new footprint, as well as export its properties into a yaml file (or import an existing one). If the 3D-scripts are embedded, you could furthermore create the 3D-files with the same script and data files. Both from a gui as well as cli.

from kicad-footprint-generator.