Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ENH] Using some Python coding best practices for open source repositories #105

Open
fabianegli opened this issue Apr 4, 2022 · 5 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@fabianegli
Copy link
Collaborator

I propose that tis project adopts some of the standard Python development tools to make contributions easier and reduce some of the burden of new contributors.

  • black and black-disable-checker for code formatting
  • isort to systematically sorting the imports
  • pylint to spot and fix mistakes, errors and code smells

Further tools that are not yet very useful here but might become handy in the future

  • blacken-docs for documentation
  • mypy if type annotations become a thing in this package.
@fabianegli fabianegli added enhancement New feature or request help wanted Extra attention is needed labels Apr 5, 2022
@ypriverol
Copy link
Member

Agreed. Do you know how we can enforce that by code or linting etc. Another question, do you know how to validate that with IDE as Pycharm?

@fabianegli
Copy link
Collaborator Author

I know how to enforce it in pull requests. I can add that to the repo.

RE PyCharm: I don't use it myself and can't immediately answer how to configure it, but I assume that it is possible.

One part is adding the necessary configuration files for the tools to the repo. For some this is only necessary if we stray awa from the default config.

isort likes to know what package is the "first-party" and I want it to force one line per import which makes the (git) diffs much more sensible.

I just saw in the CI of my last PR that this repo already uses pyre. Is there anyone here who has a preference for either? Using pyre instead of my initial proposal mypy is fine with me. And I think if you disable push to the master branch and only allow merging after successful checks, the type checking should be sufficiently enforced.

@fabianegli
Copy link
Collaborator Author

For the branch protection an admin needs to go to Setttings -> Branches and then click the "Add rule" in the "Branch protection rules" section, type the name of the branch to be protected (master) and then check at least the top two protections "Require a pull request before merging" and "Require status checks to pass before merging". That should do it.

@fabianegli fabianegli changed the title [CODE] Using some Python coding best practices for open source repositories [MAINT] Using some Python coding best practices for open source repositories Apr 5, 2022
@ypriverol
Copy link
Member

I will protect the master.

@ypriverol
Copy link
Member

For the branch protection an admin needs to go to Setttings -> Branches and then click the "Add rule" in the "Branch protection rules" section, type the name of the branch to be protected (master) and then check at least the top two protections "Require a pull request before merging" and "Require status checks to pass before merging". That should do it.

DONE.

@fabianegli fabianegli changed the title [MAINT] Using some Python coding best practices for open source repositories [ENH] Using some Python coding best practices for open source repositories Apr 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants