-
Notifications
You must be signed in to change notification settings - Fork 11
Contributor Guide
The general idea is to separate ongoing work from the master branch (main development history). This will help ensuree that no accidental and unwanted changes will be pushed to overwrite the main codebase. Thus, a following workflow should be kept at all times:
- Start working on a new feature.
- Synchronize the local repository with the remote
This is done usually by invoking:
git pull --rebase origin <branch>, where<branch>is the name of a branch to which one synchronizes, usually this will be the master branch. - Create a new branch for feature development with
git checkout -b <branch name>. - Work on a feature on the new branch and make as many commits as needed.
- When done, push the new branch to the repository and create a pull request. You can read more about pull requests here and here.
- The team discusses the propose changes and apply corrections and adjustments if needed.
- When everyone agree that the feature is ready, the new branch is merged with a target branch (usually the master branch) by the repository owner.
The above workflow is an example of shared repository approach. An alternative called fork-and-pull approach is based on everyone working on a completely separate forks of the main repository and doing between repository pull requests. This approach seems to be a little bit of an overkill for a team of few persons.
At least for the beginnign let's try to keep to the PyLint configuration provided in the repo.
It is preferable, especially in the longterm, to follow the Test Driven Development approach. This is about writing modular code (decompose complicated logic into simple methods/functions) alongside with unit tests (simple automatically run functions that test the implementations).
PyTest is a very powerful and flexible library for unit testing, so it seems to be a good choice for this. It is quite complicated in advanced usecases, but standard usage is extremely simple. It also make benchmarking and profiling code very easy.
I recommend to use the so-called
Numpy style
documentation. It makes it very easy to read docstrings in the source code and
is not to hard to write (check the skeleton code of the BDM class).
It can also utilize all the power of the
reStructuredText
markup.
Here is a short list of extensions for the VS Code IDE, that are often useful:
- Python extension
- Anaconda extension pack (for those who use Anaconda python distribution)
- RST preview (useful for previewing reStructuredText files, such as this README)