-
Notifications
You must be signed in to change notification settings - Fork 13
Installation
If your system is already setup for development with:
- Python 2.7 or 3.4,
- Django 1.8,
- PostgreSQL 9.2 or later, and
- Memcached
then the basic installation docs might be enough. These pages are for the rest of us.
- [Installation on OS X](Installation on OS X)
- [Installation on Ubuntu](Installation on Ubuntu)
Ideally, you should install:
- Python 2.7 and 3.4, with development packages
- pip, virtualenv, and virtualenvwrapper as system packages
- Production and development Python packages inside a virtualenv
The code is written for Python 2.7 and 3.4, using Django's Python 3 porting strategy. Production uses Python 2.7, but 3.4 appears to be the first 3.x version that is widely supported by 3rd-party software developers, and may become the only supported version. We test Python 2.7 and 3.4 compatibility with tox, which can be run locally with tox. When commits are pushed to the GitHub repository, TravisCI runs the tests using tox as well.
Linux distributions often split the runtime and development packages. For example, there will be a python package that includes the Python executable and the standard library, and a python-dev package that includes the header files and linking libraries needed to build C-based Python libraries. You'll need the development packages to build some of the packages used by the project.
virtualenv is recommended for this project, and Python development in general. It creates a Python "virtual environment" that installs packages and executable in a separate structure, keeping your base operating system clear of cruft and avoiding versions collisions between projects. It is even possible to install non-Python code, such as Node.js into the virtual environment, to allow use of the growing ecosystem of node-based tools (such as JSLint) without colliding with other projects. It may also be useful to have two environments, a Python 2.7 and a Python 3.4 variant, to ease working on Python2/3 issues.
virtualenvwrapper adds some scripts, such as mkvirtualenv wpc and workon wpc, that make it easy to work with virtualenv.
pip makes it easy to install Python packages. When used normally, it install system-level packages. Inside a virtualenv, it installs packages to the virtualenv. The project uses the standard convention of a requirements.txt for required package definitions, which can be installed with pip install -r requirements.txt. Additional packages used for project development are installed with pip install -r requirements.dev.txt.
Although the Django ORM abstracts away most differences between database engines, there are some unavoidable differences that will cause Django using one database to behave slightly differently than another database. If possible, you should use the same database in development as in production, and avoid many subtle bugs.
The beta server at https://browsercompat.herokuapp.com runs against PostgreSQL, version 9.3.3. This version or later is recommended for local development.
memcached is an in-memory cache that used to speed up sessions and read-access to the API. It is fairly easy to run in the development environment as well. Django's cache framework is used to provide an abstract cache interface, so an alternate cache engine like Redis could be substituted, with less side effects than using a different database engine.
Redis is a newer caching engine, that adds support for richer data structures such as lists and sets. It can be used as the Django cache, and is also suitable as the broker and results backend for Celery.
celery is a asynchronous task queue system, which the project uses for long-running tasks and to make web requests more responsive. In production, we plan to add additional components, such as RabbitMQ, to make celery run tasks asynchronously. In beta, we run Celery using Redis as the backend broker and result engine. When running async, operations such as importing an MDN page will return faster, but won't be complete until a few seconds later.
In development, we default to "eager" mode, meaning that tasks run synchronously. In eager mode, some operations will take longer, and the browser will wait until the operation is complete.