This project is just an example showcase of my https://github.com/JonasPammer/cookiecutter-pypackage project.
This package is available at PyPi.
I recommend you to install using pipx - a tool that helps installing and running end-user applications written in Python without worrying about any virtualenv magic:
$ pipx install test_application
But you can of course also install it using normal pip or in your virtual environment:
$ python3 -m pip install test_application
This Project also offers a best-practiced Dockerfile to run this package in an ensured-to-be-working environment:
Details in README_DOCKER.
The current major version is supported. For example, if the current version is 3.4.1:
| Version | Supported |
|---|---|
v3.4.1 |
✅ |
v3.4.x |
✅ |
v3.x.x |
✅ |
v2.x.x |
❌ |
v1.x.x |
❌ |
Please report (suspected) security vulnerabilities to opensource@jonaspammer.at, preferably with a proof of concept.
You may use the following template for your e-mail (text in underscores (_) is meant for guidance of filling out the form and can be removed):
## Severity _One of Low, Moderate, High, Critical, or "Asses using Common Weakness Enumarator found in Reference"_ ## CVE Identifier (https://cve.mitre.org/cve/search_cve_list.html) None ## Description ## Reproduction _Step-by-step instructions to reproduce the issue / Proof-of-concept / Any special configuration needed to reproduce / Exploit Code_ ## Impact _What kind of vulnerability is it (Injection, XSS, Overflow, ...)? Who is impacted?_ ### Patches _Has the problem been patched? What versions?_ ### Workarounds _Is there a way for the users to fix or remediate the vulnerability without upgrading?_ ### References _Are there any links the developer or users can visit to find out more?_
Non-vulnerability related security issues such as great new ideas for security features are welcome on GitHub Issues.
Development Dependencies are defined in a
pip requirements file
named requirements-dev.txt.
Example Installation Instructions for Linux are shown below:
# "optional": create a python virtualenv and activate it for the current shell session $ python3 -m venv venv $ source venv/bin/activate (venv)$ python3 -m pip install -r requirements-dev.txt
Installing the package locally from live source itself can be done using the following commands:
# "optional": ensure it actually works by using previously-pinned versions (venv)$ python3 -m pip install -r requirements.txt --require-hashes # install package from path in develop mode (venv)$ python3 -m pip install -e .
|
Note
|
When you alter the package definition (i.e. (venv)$ python3 -m pip install -e . |
When you change the dependencies of the pypackage (in setup.cfg)
or change one of the requirements*.in files you must run
the appropriate commands to regenerate their *.txt counterparts.
The command to run is denoted in form of a comment
at the top the respective requirements*.txt file, i.e.:
(venv)$ pip-compile --resolver=backtracking --generate-hashes (venv)$ pip-compile --resolver=backtracking requirements-dev.in (venv)$ pip-compile --resolver=backtracking requirements-build.in
Automatic Tests are run on each Contribution on all major Operating Systems (macOS, Windows, Ubuntu) and Python versions (Python 3.7+) using GitHub Workflows.
In order to run the testsuite locally you need to tell tox (the test runner) which environment (python version - pip version) you want to run as seen in the Examples below:
# use default python 3 of system $ tox -e py3 # use a specified version of python $ tox -e py37 # implicitly use default python 3 of system, ensuring the use of some fixed old pip version $ tox -e pipprevious # implicitly use default python 3 of system, ensuring the use of latest published and accessible version of pip $ tox -e piplatest # implicitly use default python 3 of system, ensuring the use of latest devel version of pip $ tox -e pipmain # mix and match the above $ tox -e py37-piplatest
In order to run the additional dockerfile smoke test
simply execute the docker_smoke_test.py file as shown below:
$ python3 docker_smoke_test.py
Versions are defined using Tags which start with v.
When a new tag is pushed,
a GitHub CI workflow
(
)
takes care of building the wheels using
build
and uploading them to PyPI using
twine.
Version Bumps shall be made through the use of
bump2version, e.g.:
$ bump2version patch or $ bump2version minor or $ bump2version major
This tool automatically updates the version string in the required files
and creates a generic commit with a matching tag
(as configured in .bumpversion.cfg).
|
Note
|
Do not forget that just git push’ing does not push tags! Use: $ git push origin <tag_name> or $ git push origin $(git describe --match "v")* |
This Project shall be kept in sync with the CookieCutter it was originally templated from using cruft (if possible) or manual alteration (if needed) to the best extend possible.
cruft update
When a new tag is pushed, an appropriate GitHub Release will be created by the Repository Maintainer to provide a proper human change log with a title and description.
General Linting and Styling Conventions are
automatically held up to Standards
by various pre-commit hooks, at least to some extend.
Automatic Execution of pre-commit is done on each Contribution using
pre-commit.ci*.
Pull Requests even automatically get fixed by the same tool,
at least by hooks that automatically alter files.
|
Note
|
Not to confuse:
Although some pre-commit hooks may be able to warn you about script-analyzed flaws in syntax or even code to some extend (for which reason pre-commit’s hooks are part of the test suite),
pre-commit itself does not run any real Test Suites.
For Information on Testing, see 🧪 Testing |
|
Tip
|
Nevertheless, I recommend you to integrate pre-commit into your local development workflow yourself. This can be done by cd’ing into the directory of your cloned project and running You can also, for example, execute pre-commit’s hooks at any time by running |
The following sections are generic in nature and are used to help new contributors. The actual "Development Documentation" of this project is found under 📝 Development.
First off, thank you for considering contributing to this Project.
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
This Project owns many of its files to the CookieCutter it was originally templated from.
Please check if the edit you have in mind is actually applicable to the template and if so make an appropriate change there instead. Your change may also be applicable partly to the template as well as partly to something specific to this project, in which case you would be creating multiple PRs.
A casual contributor does not have to worry about following the spec by definition, as pull requests are being squash merged into one commit in the project. Only core contributors, i.e. those with rights to push to this project’s branches, must follow it (e.g. to allow for automatic version determination and changelog generation to work).
Contributions are made to this repo via Issues and Pull Requests (PRs). A few general guidelines that cover both:
-
Search for existing Issues and PRs before creating your own.
-
If you’ve never contributed before, see the first timer’s guide on Auth0’s blog for resources and tips on how to get started.
Issues should be used to report problems, request a new feature, or to discuss potential changes before a PR is created. When you create a new Issue, a template will be loaded that will guide you through collecting and providing the information we need to investigate.
If you find an Issue that addresses the problem you’re having, please add your own reproduction information to the existing issue rather than creating a new one. Adding a reaction can also help be indicating to our maintainers that a particular problem is affecting more than just the reporter.
PRs to this Project are always welcome and can be a quick way to get your fix or improvement slated for the next release. In general, PRs should:
-
Only fix/add the functionality in question OR address wide-spread whitespace/style issues, not both.
-
Add unit or integration tests for fixed or changed functionality (if a test suite already exists).
-
Address a single concern
-
Include documentation in the repo
-
Be accompanied by a complete Pull Request template (loaded automatically when a PR is created).
For changes that address core functionality or would require breaking changes (e.g. a major release), it’s best to open an Issue to discuss your proposal first.
In general, we follow the "fork-and-pull" Git workflow
-
Fork the repository to your own Github account
-
Clone the project to your machine
-
Create a branch locally with a succinct but descriptive name
-
Commit changes to the branch
-
Following any formatting and testing guidelines specific to this repo
-
Push changes to your fork
-
Open a PR in our repository and follow the PR template so that we can efficiently review the changes.
Please refer to the Release Page of this Repository for a human changelog of the corresponding Tags (Versions) of this Project.
Note that this Project adheres to Semantic Versioning. Please report any accidental breaking changes of a minor version update.
MIT License Copyright (c) 2022, Jonas Pammer Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.