Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.
You can contribute in many ways:
Report bugs at https://github.com/antscloud/fretboardgtr/issues.
If you are reporting a bug, please include:
- Your operating system name and version.
- Any details about your local setup that might be helpful in troubleshooting.
- Detailed steps to reproduce the bug.
Look through the GitHub issues for bugs. Anything tagged with "bug" and "help wanted" is open to whoever wants to implement it.
Look through the GitHub issues for features. Anything tagged with "enhancement" and "help wanted" is open to whoever wants to implement it.
FretBoardGtr could always use more documentation, whether as part of the official FretBoardGtr docs, in docstrings, or even on the web in blog posts, articles, and such.
The best way to send feedback is to file an issue at https://github.com/antscloud/fretboardgtr/issues.
If you are proposing a feature:
- Explain in detail how it would work.
- Keep the scope as narrow as possible, to make it easier to implement.
- Remember that this is a volunteer-driven project, and that contributions are welcome :)
Ready to contribute? Here's how to set up fretboardgtr
for local development.
-
Fork the
fretboardgtr
repo on GitHub. -
Clone your fork locally:
$ git clone [email protected]:your_name_here/fretboardgtr.git
-
Install your local copy into a virtual environment.
- With
venv
: Assuming you havevenv
installed, this is how you set up your fork for local development :
cd fretboardgtr/ python -m venv <name_of_your_env> pip install -e .[dev]
- With
conda
: Assuming you have conda installed, this is how you set up your fork for local development :
cd fretboardgtr/ conda create -n <name_of_your_env> python=3.10 conda activate <name_of_your_env> pip install -e .[dev]
- With
-
Install the pre-commit hooks by running :
pre-commit install
-
Make sure you have
git-lfs
installed, then rungit lfs install
. -
Create a branch for local development:
git checkout -b name-of-your-bugfix-or-feature
Now you can make your changes locally.
-
When you're done making changes, apply the pre-commit and check that your changes pass the tests, including testing other Python versions.
pre-commit fretboardgtr tests python -m pytest
-
If files are modified by the pre-commit hooks, you need to rea-add them :
git add <your-modified-files>
-
Commit your changes and push your branch to GitHub:
git add . git commit -m "Your detailed description of your changes." git push origin name-of-your-bugfix-or-feature
-
Submit a pull request through the GitHub website.
Before you submit a pull request, check that it meets these guidelines:
- The pull request should include tests.
- If the pull request adds functionality, the docs should be updated. Put your new functionality into a function with a docstring, and add the feature to the list in README.rst.
- The pull request should work for Python 3.5, 3.6, 3.7 and 3.8, and for PyPy. Check https://github.com/antscloud/fretboardgtr/pull_requests and make sure that the tests pass for all supported Python versions.
To run a subset of tests :
python -m pytest tests.test_fretboardgtr
A reminder for the maintainers on how to deploy. Make sure all your changes are committed.
Go to fretboardgtr/_version.py and bump the version to the version you want.
Let's say from 0.2.0
to `0.2.1.
< version_str = "0.2.0"
> version_str = "0.2.1"
Then commit this change
git commit -m "Bump version 0.2.0 to 0.2.1" -m "<What changed>" -m "More descriptive message"
git tag -a "0.2.1" -m "Bump version 0.2.0 to 0.2.1" -m "<What changed>" -m "More descriptive message"
git push origin master --tags
This will then deploy the package in PyPI if tests pass and a tag is set, otherwise it will deployed on test-pipy.
The changelogs are generated using [git cliff][https://git-cliff.org/]. This is a rust utility tool that can be downloaded with cargo
.
The configuration file for this tool is cliff.toml
.
After modifying the _version.py
file as described above please simply run :
git cliff -o CHANGELOG.md
git add CHANGELOG.md
git commit -m "docs: Auto-generated changelog"
git push origin master
Most of the pre-commit hooks require you to do nothing but save the changes. However, some pre-commits (e.g. pydocstyle
) are sometimes hard to respect and can slow down your workflow. Although we recommend to let all of them to have a cleaner repo, if one or more are really annoying for you, you can remove or comment them in the .pre-commit-config.yaml
file.
Before each commit, each hook is going to run against file in the staged area (files added with git add
). Some of the hooks may modify the files, if this happened, the commit is cancelled. You need to re-add the file(s) modified by running git add <modified-file>
and recommit.
Although it is not mandatory, we suggest you to use the Conventional Commit conventions to write commit messages.