Reports / April 2020

Django REST framework

While there has been a bunch of triage and minor fixes, our 3.12 release is still pending. I’ll be looking at resolving this as a priority for May.


We’ve now issued a 0.13 pre-release for httpx. You can install this release using pip install httpx --pre.

The 0.13 release is a big milestone since it drops urllib3 for the sync client, and instead uses httpcore for both the async and the sync clients.

This means that:

In order to make this possible, we’ve dropped support for a lesser-used feature of being able to make requests directly to a Unix domain socket.

We’ll give our pre-release a while to get bedded-in, before promoting it to a full 0.13 release. At that point we’re ready to start reviewing any final API points that need addressing prior to a 1.0 release.


The dashboard package is the first-pass of an admin-like interface for Starlette and other ASGI frameworks.

Dashboard is designed to be able to plug directly into the ORM package, but may also to be used with alternate datasources too. A DataSource interface provides the contract that is required for alternate implementations.

The package currently depends on pre-release versions of orm and typesystem, and is still very much in a design stage, but you’ll be able to get a bit of an idea of how the API looks from the README.

Project management improvements

The scope of the async web stack has been growing over the last few months, so that we’re now maintaining several projects in this space, including uvicorn, starlette, databases, orm, typesystem, broadcaster, httpcore, and httpx.

In order to keep scaling the maintenance work on those projects we’ve made some changes to the project management approach:

It’s worth talking through our GitHub Action workflows a little, since they might be valuable for other teams working with PyPI and MkDocs.

Our workflow approach

We follow GitHub’s “Scripts to Rule Them All” pattern for install, deploy, and test scripts.

Any complexity is kept out of the workflow steps, which just call into the scripts. For example, here’s the “steps” configuration for our Test Suite workflow:

  - uses: "actions/checkout@v2"
  - uses: "actions/setup-python@v1"
      python-version: "$"
  - name: "Install dependencies"
    run: "scripts/install"
  - name: "Run linting checks"
    run: "scripts/check"
  - name: "Build package & docs"
    run: "scripts/build"
  - name: "Run tests"
    run: "scripts/test"

Deploying to PyPI

We’ve created an API token for each PyPI package, and then stored that in the repo secrets as PYPI_TOKEN.

The workflow file uses the API token to setup an appropriate environment for the publish script to run with…

  TWINE_USERNAME: __token__

Once we’ve done that we’re able to either:

Our publish workflow is setup to run whenever a release is tagged in GitHub…

      - '*'

Deploy the docs, using MkDocs

Deploying the documentation from a GitHub action is simple enough. We can use mkdocs gh-deploy to push a documentation release to the gh-pages branch.

There’s two extra things we need to take care of…

To set the Git user when we’re running the deploy script as a GitHub action we use the following…

if [ ! -z "$GITHUB_ACTIONS" ]; then
  git config --local "41898282+github-actions[bot]"
  git config --local "GitHub Action"


The email address there happens to be the GitHub Action bot’s designated email, which ensures that commits to the gh-pages branch display the bot avatar properly in the GitHub interface.

Thanks as ever to all our sponsors, contributors, and users,

— Tom Christie, 1st May, 2020.