adding pre-commit hooks

[axiomcura]

This small PR introduces pre-commits for cytosnake.

The main file to look at is the .pre-commit-config.yaml file, which contains the programs that will be executed in order to keep the cytosnake's code base to a specific standard.

[axiomcura]

Formatting issues are all fixed!

Comments from @d33bs

I noticed that .pre-commit-config.yaml is found under the docs dir. Would it make sense to move it to the root or a root .config directory?

That was a mistake! Moved it to the root directory folder.

Would it make sense to add developer or contributor documentation outlining how one might use pre-commit with this repository?

Yes, this is a good point. However, my assumption of pre-commits is that it is automatically executed when a developer submits a commit. Are you suggesting documenting the types of tools that are executed in the pre-commit configs?

In addition, pre-commit does provide developers to manually execute the pre-commit hooks by typing pre-commit run.

I feel that this can be written in the README and in the sphinx docs.

[d33bs]

@axiomcura - Thanks for the replies, and nice work making changes! Replying to your question below.

Yes, this is a good point. However, my assumption of pre-commits is that it is automatically executed when a developer submits a commit. Are you suggesting documenting the types of tools that are executed in the pre-commit configs?

Tools like pre-commit can help reduce the time and development friction by turning assumptions into reproducible expectations for a repository. However, because pre-commit may be used in so many ways (as a hook, as a manual check, within automated tooling) and there are fewer guarantees about a developer's environment + workflow it might be helpful to consider spelling out how you see it being used. For example, in some repos it's a suggestion for development, in others it may be a requirement. From the perspective of this repo, how do you see it being used by yourself or others (this could go into the docs)?

[axiomcura]

@d33bs Ahh I see what you're saying.

Since I am using a package called pre-commit I should let users know on how to use it. You are right, there are many methods on how to use pre-commits I just happen to use it by downloading a package known as pre-commit; therefore, I must explicitly state on how the pre-commits are used through this tool.

Correct me if I am wrong.

[d33bs]

@axiomcura - thanks, yes, I recommend being clear within documentation on how pre-commit should be used. For example, if another developer were to make a contribution to this repo, how likely would it be that their work would require corrections which could have otherwise been caught by pre-commit (and not a reviewer)? If they could have used pre-commit in such a way to prepare the code in advance of a review, I'd recommend documenting the suggested or required methods for doing so. Specifically I'm meaning running pre-commit for this repo in a broad sense, and not which checks or how those checks work (which is outlined within the configuration file).

[axiomcura]

@d33bs Thanks Dave. I'll make this an issue and take care of once we are close to production! Thank you for your insights!