Before we can write code, we need to set up the environment. We could perhaps look at cookiecutter, but we need to include:

Environment & Build

• Pipenv
• Make
• Travis

Dev Requirements

• pytest test runner with coverage
• flake8
  • mccabe
  • docstring
• bandit
• radon
• lettuce
• sphinx

Requirements

• pydriller
• click

What needs to be done for v0.1.0 README

• Write title and intro paragraph
  • Make it engaging and evocative
  • Write out a list of pain points
• Rewrite the opening paragraph
• Outline how to get started quickly
• Rewrite the getting started outline
• List the commands and their usage with examples
• Complete configuration examples with working Python code
• Document the default commit ranges for each hook

What can be done at a later release:

• Create a logo
• Create a video gif of usage
• Full tutorial on example project (maybe separate issue) or micro-examples of:
  • Webpack
  • Django
  • Coverage
  • Linting
  • Provisioning
• List configuration options
  • Templating
  • Types & valid values
  • Purpose
  • Example
  • Outcome

What needs documenting?

End users should know which commit ranges are applied by default, to see if they meet their needs. These commit ranges should be configurable to the developer's liking. This documentation makes it easier to tweak enguard with modified commit ranges.

Build is failing on a version of python due to package resolution. Is there a way to fix this? The difference in the zipp package is a major version!

What are we trying to do?
We need to test enguard end-to-end in multiple environments with multiple python versions. This tool may be used on Mac, Linux, Windows and in a Docker container, to name a few.

Why are we trying to do this?
So that Enguard is shown to have at least some stability across common usage environments. The first initial users will be myself and my team so testing on Mac will be helpful. Testing inside a docker container will come next - this will help easily establish Enguard's utility in fresh environments.

How does this experiment help?
This experiment will help us understand what Enguard needs to run across a variety environments. And, crucially, how to automatically test all of those environments.

What do we hope to learn?
I hope to personally learn how we can use Docker to setup a multi-environment test rig.

Make use of static typing where possible

What is the goal of the project?
The Gold Standard is a list of minimums that must be set up on day zero at the start of a project.

Tasks:

• Automated acceptance tests
• Continuous Integration
• Automated releases
• Test categorization
• Commit, push and merge guards

What are we trying to do?
We want to enforce code coverage in projects.

Why are we trying to do this?
If we're bootstrapping a project, we might want to enforce a no-uncovered-code rule. But, so this is incremental, we only want to fail on changed code. But we don't want to restrict this to Python tooling. I, for example, know of PHP, Python, TypeScript and JS projects I can use Enguard on.

How does this experiment help?
This experiment will show how Enguard can enforce this coverage in a sane way between commits and pushes.

What do we hope to learn?
How Enguard can help enforce coverage in a flexible, polyglottal way.

What are we trying to do?
Get a list of files from git on an incoming merge.

Why are we trying to do this?
We want to know if integrating changes from remote or another branch breaks our build. Further, if we need to resolve merge conflicts, we want to quickly find defects caused so we can find them and fix them quickly.

How does this experiment help?
This will establish the straight-forward way to get a list of files on incoming merge.

What do we hope to learn?
What are the options on the post-merge hook? Does this hook run after a merge commit after fixing conflicts? And if not, is there a way to postpone until after merge conflicts are resolved?

What needs documenting?

Just a basis for a comprehensive set of docs.

What is the goal of the documentation?

The goal is to provide a comprehensive guide to Enguard. I can't do that all at once but having a structure in place where I can document the project and automatically build new docs is important.

Who is the expected audience?

• Newcomers looking to get started and integrate with their projects

• Experienced users looking for references

• Core developers, building new features and fixing bugs

• How does this documentation solve their problems?

By providing one place and one source of truth for how Enguard works, inside and out.

Refactor utils to a referentially transparent Repo object, returning commands to run instead of performing side effects.

What is the goal of the project?
Release the first working version of Enguard.

Tasks:

• #1 - Write the README
• #5 - Setup mypy
• Setup setup.py
• Setup dev dependencies
• Configure flake8
• Configure black
• Set up 'check' script that runs mypy, flake8
• Sketch out what the watch mode interface should look like
• Insert example run gif
• Expand configuration example with working Python code
• Fix failing mypy errors
• Configure CI (GitHub Actions?)

I need to expand this - writing the README will tell me what features I need

What are we trying to do?
We only really want to look at the files affected. On a project using Git, we want to prevent pushes to remotes if we know they will fail the build.

Why are we trying to do this?
It's a waste parsing and linting files that haven't changed. And we don't want other people's changes failing our build - these might be changes that are in the process of being improved.

How does this experiment help?
The results of this experiment will establish how we accomplish retrieving the list of changed files in Git. This may be using GitPython, PyDriller or using bash.

What do we hope to learn?
We hope to find the way with least headache for now. If a solution takes more work but is potentially more performant, we should earmark it if it becomes a bottleneck.

What are we trying to do?
We need to try and setup githooks that notify Enguard.

Why are we trying to do this?
This is a crucial part of Enguard's feature set. Most of Enguard's functionality will be invoked via git hooks.

How does this experiment help?
By writing the code for registering git hooks, we can get a feel for the problem and design a solution that works.

What do we hope to learn?
I want to know the edge cases around registering githooks. I'd like a complete list of git hook states. What happens upon failure? What happens if there exists githooks - is there a mechanism for concurrent hooks?

What is the goal of the project?
I need to validate my ideas on how to solve certain problems. I can use the code and results as a reference for feature implementation.

Tasks:

• Set up experiments module and tests
• Getting list of files changed for incoming commit
• #17 - Acceptance testing a CLI
• #13 - Registering githooks
• #14 - Getting list of files changed between current push and previous
• #15 - Getting list of files incoming in a merge
• #16 - Enforcing code coverage
• Creating and tearing down a fake git repo