sqlite-utils takes place in the sqlite-utils GitHub repository.
All improvements to the software should start with an issue. Read How I build a feature for a detailed description of the recommended process for building bug fixes or enhancements.
Obtaining the code#
To work on this library locally, first checkout the code. Then create a new virtual environment:
git clone email@example.com:simonw/sqlite-utils cd sqlite-utils python3 -mvenv venv source venv/bin/activate
Or if you are using
Within the virtual environment running
sqlite-utils should run your locally editable version of the tool. You can use
which sqlite-utils to confirm that you are running the version that lives in your virtual environment.
Running the tests#
To install the dependencies and test dependencies:
pip install -e '.[test]'
To run the tests:
Building the documentation#
To build the documentation, first install the documentation dependencies:
pip install -e '.[docs]'
make livehtml from the
docs/ directory to start a server on port 8000 that will serve the documentation and live-reload any time you make an edit to a
cd docs make livehtml
The cog tool is used to maintain portions of the documentation. You can run it like so:
cog -r docs/*.rst
Linting and formatting#
Black is installed as part of
pip install -e '.[test]' - you can then format your code by running it in the root of the project:
flake8 run the following:
pip install -e '.[flake8,mypy]'
Both commands can then be run in the root of the project like this:
flake8 mypy sqlite_utils
All three of these tools are run by our CI mechanism against every commit and pull request.
Using Just and pipenv#
To create a virtual environment and install all development dependencies, run:
cd sqlite-utils just init
To run all of the tests and linters:
To run tests, or run a specific test module or test by name:
just test # All tests just test tests/test_cli_memory.py # Just this module just test -k test_memory_no_detect_types # Just this test
To run just the linters:
To apply Black to your code:
To update documentation using Cog:
To run the live documentation server (this will run Cog first):
And to list all available commands:
Releases are performed using tags. When a new release is published on GitHub, a GitHub Actions workflow will perform the following:
Run the unit tests against all supported Python versions. If the tests pass…
Build a wheel bundle of the underlying Python source code
Push that new wheel up to PyPI: https://pypi.org/project/sqlite-utils/
To deploy new releases you will need to have push access to the GitHub repository.
sqlite-utils follows Semantic Versioning:
major for backwards-incompatible releases.
minor for new features.
patch for bugfix releass.
# Update changelog git commit -m " Release 3.29 Refs #423, #458, #467, #469, #470, #471, #472, #475" -a git push
Referencing the issues that are part of the release in the commit message ensures the name of the release shows up on those issue pages, e.g. here.
You can generate the list of issue references for a specific release by copying and pasting text from the release notes or GitHub changes-since-last-release view into this Extract issue numbers from pasted text tool.
To create the tag for the release, create a new release on GitHub matching the new version number. You can convert the release notes to Markdown by copying and pasting the rendered HTML into this Paste to Markdown tool.