Preferred packages

We have preferences in order to:

  • Limit the number of packages with which developers need to be familiar.
  • Re-use code (like Click) instead of writing new code (with argparse).

For Applications, we prefer all-inclusive and opinionated packages, because they:

  • Encourage greater similarity and code re-use across projects. With Django, for example, developers are encouraged to use its authentication mechanism. With Flask, each developer can choose a different mechanism, or write their own.
  • Are more robust to changes in scope. For example, you might not need the Django admin site on day one, but you’ll be happy to have it when it becomes a requirement.
Web framework
Django LTS, unless a newer version has desirable features. Do not use Flask, except in limited circumstances like generating a static site with Frozen-Flask.
No preference. Consider Django Tastypie, Django REST Framework or FastAPI.
Command-line interface
Click, unless a framework provides its own, like Django or Scrapy. Do not use argparse.
Object Relational Mapper (ORM)
Django. If you don’t need an ORM, use psycopg2. Do not use SQLAlchemy, except in low-level libraries with limited scope where an ORM is needed.
HTTP client
Requests, unless a framework uses another, like Scrapy (Twisted).
HTML parsing
lxml. Do not use BeautifulSoup.
gettext, Babel and transifex-client, unless a framework provides an interface to these, like Django or Sphinx.
pytest, unless a framework uses another, like Django (unittest).
Sphinx. Its Markdown extensions should only be used for OCDS documentation.

Maintainers can find dependencies with:

find . \( -name '' -or -name '' \) -exec echo {} \; -exec cat {} \;