To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.
…should all be reported on the GitHub Issue Tracker .
PEP 8, when sensible.
Test ruthlessly. Write docs for new features.
Even more important than Test-Driven Development–Human-Driven Development.
…should be released as a separate package.
Pull requests adding support for another framework will not be accepted. In order to keep webargs small and easy to maintain, we are not currently adding support for more frameworks. Instead, release your framework integration as a separate package and add it to the Ecosystem page in the GitHub wiki .
Fork webargs on GitHub.
$ git clone https://github.com/marshmallow-code/webargs.git $ cd webargs
Install development requirements. It is highly recommended that you use a virtualenv. Use the following command to install an editable version of webargs along with its development requirements.
# After activating your virtualenv $ pip install -e '.[dev]'
(Optional, but recommended) Install the pre-commit hooks, which will format and lint your git staged files.
# The pre-commit CLI was installed above $ pre-commit install
webargs uses black for code formatting, which is only compatible with Python>=3.6. Therefore, the
pre-commit install command will only work if you have the
python3.6 interpreter installed.
Webargs abides by the following branching model:
Current development branch. New features should branch off here.
Maintenance branch for release
X.Y. Bug fixes should be sent to the most recent release branch.. The maintainer will forward-port the fix to
dev. Note: exceptions may be made for bug fixes that introduce large code changes.
Always make a new branch for your work, no matter how small. Also, do not put unrelated changes in the same branch or pull request. This makes it more difficult to merge your changes.
Create a new local branch.
# For a new feature $ git checkout -b name-of-feature dev # For a bugfix $ git checkout -b fix-something 1.2-line
Commit your changes. Write good commit messages.
$ git commit -m "Detailed commit message" $ git push origin name-of-feature
Before submitting a pull request, check the following:
If the pull request adds functionality, it is tested and the docs are updated.
You’ve added yourself to
4. Submit a pull request to
marshmallow-code:dev or the appropriate maintenance branch.
The CI build must be passing before your pull request is merged.
To run all tests:
To run syntax checks:
$ tox -e lint
(Optional) To run tests on Python 2.7, 3.5, 3.6, and 3.7 virtual environments (must have each interpreter installed):
To build the docs in “watch” mode:
$ tox -e watch-docs
Changes in the
docs/ directory will automatically trigger a rebuild.