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.
API
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.
Templating
Jinja
Translation
gettext, Babel and transifex-client, unless a framework provides an interface to these, like Django or Sphinx.
Logging
logging
Testing
pytest, unless a framework uses another, like Django (unittest).
Coverage
Coveralls
Documentation
Sphinx. Its Markdown extensions should only be used for OCDS documentation.

Maintainers can find dependencies with:

find . \( -name 'setup.py' -or -name 'requirements.in' \) -exec echo {} \; -exec cat {} \;