alexlatchford
commented
4 years ago As with anything like this it requires a cost/benefit analysis, likely this is a well known problem to all but here's my best shot anyway.
Costs
- Ongoing burden on contributors to adhere to best practices, this may be particularly cumbersome if a decision is made to enable static analysis.
- Temporary burden on contributors whose work is in progress when we expose stylistic constraints.
- Cost to new contributors to learn how to use toolset.
Benefits
- Auto-formatters don't always play nice with linters but for the most part if we can make the two pieces work together we can reduce pull request code churn by assuring we all play by the same rules.
- Reduce ongoing code maintenance to offloading formatting tasks to IDEs (ie.
vscodeand/orpycharmboth could integrate easily withyapf). - Static analysis can find some bugs, but mostly it will drastically improve API documentation by enforcing type adherence.
To go a little deeper my interest in contributing to Kubeflow is around how to make it easily accessible to Data Scientists without strong engineering fundamentals. Obviously this is a large goal but the barrier at the moment has not been a lack of functionality but rather the confusing nature of the model of KFP SDK concepts and cohesive documentation.
Bobgy
stale[bot]
k8s-ci-robot
rimolive
google-oss-prow[bot]
As a part of some work I did this week (see https://github.com/kubeflow/pipelines/pull/4218) to clean up the SDK docs I noticed how variable the codebase standards for the Python SDK are. Looks like are some docs in the contribution guide that suggest a style, see here, and these choices seem perfectly reasonable to me.
My question is do we think it's worthwhile trying to enforce these standards? And, if so how do we want to migrate the existing code to use this?
I'm happy to volunteer to do the grunt work to make this happen but really I'd want agreement and buy-in as typically this would cause huge merge conflicts with any work in flight if we decided to do this.