- How to contribute to scared library
- The developer workflow
- Pre-requisites
- Testing
- Code style and formatting
- Docstrings
This guide describes all you need to know to develop, test, build and distribute scared library.
- have an issue on Gitlab. No issue, no dev.
- checkout the project
- create a branch from the master or identify the branch you should be working on, be it a feature or a bug branch. Reference the issue number in the branch name
- work on the branch
- commit often small functionnal perimeter - some passing tests with it's working code. Typical commit frequency is several times each day - several begins at 2 …
- push less often, but regularly. Typical push frequency is daily.
- when work is finished, ask for final review and merge request to the upstream.
You need Python 3.6 installed. To easily get and manage Python versions, see Anaconda distributions - for example Miniconda
You can use pip with or without virtualenv, conda to manage your dependencies locally.
The project is configured to use pytest for as a runner for testing.
To run all the test suite, simply run from you directory:
pytestYou can use both the basic Python unittest package, or pytest to develop your test cases. pytest allows for less verbose tests and is recomended.
As far as possible, tests should reflects the organization of the source code. Create folders and keep everything as clean as possible.
You must follow the Python standards defined by PEP8. The only exception is that the maximum line length is 160 characters. Google style guide is a good complementary source, but is not used as a reference.
flake8 is a Python linting tool wrapping other tools, used to lint Python code around:
- PEP8 style guide with
pycodestyle - check for errors (unused import for example) with
pyflakes - check for McCabe complexity with
mccabe
The library pep8-naming is also use, through flake8 plugin, to check PEP8 naming conventions.
The linter configuration is in .flake8 file. It defines the law for the project.
You have to install a pre-commit hook, from the root of the project:
flake8 --install-hook git
git config --bool flake8.strict trueYou will not be able to commit any Python file if some errors are reported by flake8 when you try to commit.
You are strongly encouraged to configure your preferred text editor / environment development to get realtime linting when you edit files. A lot of plugins exist - check you tools documentation to set up your environment.
Additionally, you can lint your code on the command line, by simply launching flake8 from your virtualenv on a file:
flake8 my_file.pyEach public API should be documented following PEP257.
It is up to you to decide if a there is a value in a docstring. In some cases, there is no value in a docstring for trivial methods or functions, like getters and setters ( but, well, maybe you shouldn't do too much getters and setters).
For private APIs, it is up to you to decide if there is value in documentation and code comments.
We use the Google style guide conventions for docstrings, and the API documentation is generated by Sphinx.
- As far as possible, arguments and return types should be documented.
- Google docstring examples - Really complete examples
- Support of Google docstring in Sphinx, with the list supported section headers
- Python domain directives in Sphinx, to enhance API documentation with cross-linking
The flake8-docstrings plugin is used to check for your doc strings. However, errors related to missing docstring are ignored. Presence of a dosctring should be a human decision ( based on the principle that each public API should be documented ).
If you need it, you can check for missing docstrings by running:
flake8 --select D1 <path_or_filename>