Thank you for considering contributing to Tekore! If you've found a bug or would like to propose a feature, please submit an issue.
If you'd like to get more involved, here's how. There are many valuable contributions in addition to contributing code! If you're so inclined, triaging issues, improving documentation, helping other users and reviewing existing code and PRs is equally appreciated!
The rest of this guide focuses on development and code contributions.
Start by cloning the most recent version, either from the main repository or a fork you created, and installing the source as an editable package. Using a virtual environment of your choice for the installation is recommended.
$ git clone https://github.com/felix-hilden/tekore.git
$ cd tekore
$ pip install -e .
$ pip install -r requirements/dev
The last command installs all the necessary dependencies for development.
If you forked, consider adding the upstream repository as a remote to easily update your main branch with the latest upstream changes. For tips and tricks on contributing, see how to submit a contribution, specifically opening a pull request.
The installation can be verified, and any changes tested by running tox.
$ tox
Now tests have been run along with other checks and a documentation build. Tests against the live Web API use environment variables for credentials. These tests manipulate your data and player, but try to restore previous state insofar as it is possible. Please refer to the description of each test class for details. In order to run all tests successfully, one must specify:
SPOTIFY_CLIENT_ID
- client ID of a registered Spotify 3rd party applicationSPOTIFY_CLIENT_SECRET
- secret associated with that applicationSPOTIFY_REDIRECT_URI
- redirect URI whitelisted in application settingsSPOTIFY_USER_REFRESH
- user refresh token with all scopes
In addition, playback tests require an active Spotify device that does not have a private session enabled and an empty song queue.
Optionally TEKORE_TEST_SKIP_IS_FAIL
can be set to raise an error if some
of the tests would be skipped because of the environment has not been configured.
A number of tools are used to automate development tasks. They are available through tox labels.
$ coverage run && coverage report # execute test suite
$ tox -m docs # build documentation to docs/build/html/index.html
$ tox -m lint # check code style
$ tox -m format # autoformat code
$ tox -m build # packaging dry run
Before releasing, make sure the version number is incremented and the release notes reference the new release. Running tests once more is also good practice. Tox is used to build the appropriate distributions and publish them on PyPI. The publish script also reads credentials from a .pypirc file, so please set that up before publishing.
$ tox -m publish
If you'd like to test the upload and the resulting package, upload manually to TestPyPI instead.
$ python -m build
$ twine upload --repository testpypi dist/*
$ pip install --index-url https://test.pypi.org/simple/ sphinx-codeautolink