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 {} \;