Refactor setup.py

[hwwhww]

Issue

Our lengthy setup.py is so difficult to read. It will be more and more complicated when we introduce more feature specs.

How did I mitigate it

Break setup.py into multiple files:

• pysetup/constants.py: constants
• pysetup/helpers.py: misc helpers
• pysetup/md_doc_paths.py: the markdown file paths setting
• pysetup/spec_builders.py: the SpecBuilder implementations of each fork
• pysetup/typing.py: the NamedTuple data structures used in building the spec

I didn't move the helper functions that utilize the ruamel.yaml or marko packages, which require installation via setup.py. Despite this, I think this refactoring helps setup.py concentrate on package dependencies management.

TODO:

• not sure if it works well on pypi installation

[mkalinin]

I very much appreciate refactor towards spec modularization allowing to add a new feature in easier way.

IMO, a potential step further is coming to ./pysetup/{feature_name}.py file containing all required definitions named according to some convention, e.g. FeatureNameBuilder, feature_name_md_files, and so on, including a parent phase. Then setup.py can have a list of enabled features and can seek for required information to build a spec for particular feature relying on the convention. And spec editors will have to follow the convention which isn't that bad.

[dapplion]

This is a great step in the right direction! Adding features can become less painful in the near future