Update documentation to remove Zamboni's references (bug 990108)
This commit is contained in:
David Larlet
Родитель
621fdc4cf9
Коммит
0f29ccf894
|
|
@ -9,6 +9,6 @@ We took all the cool stuff we did in AMO, SUMO and our other websites, and
|
|||
created a base template for new websites.
|
||||
|
||||
.. _`addons.mozilla.org`: https://addons.mozilla.org
|
||||
.. _`install docs`: http://zamboni.readthedocs.org/en/latest/topics/install-zamboni/index.html
|
||||
.. _`install docs`: http://olympia.readthedocs.org/en/latest/topics/install-olympia/index.html
|
||||
.. _`irc://irc.mozilla.org/amo`: irc://irc.mozilla.org/amo
|
||||
.. _`Playdoh`: https://github.com/mozilla/playdoh
|
||||
|
|
|
|||
10
docs/conf.py
10
docs/conf.py
|
|
@ -41,8 +41,8 @@ source_suffix = '.rst'
|
|||
master_doc = 'index'
|
||||
|
||||
# General information about the project.
|
||||
project = u'zamboni'
|
||||
copyright = u'2013, The Marketplace API Crew'
|
||||
project = u'olympia'
|
||||
copyright = u'2014, The Addons Crew'
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
# |version| and |release|, also used in various other places throughout the
|
||||
|
|
@ -163,7 +163,7 @@ html_static_path = ['_static']
|
|||
#html_file_suffix = ''
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'zambonidoc'
|
||||
htmlhelp_basename = 'olympiadoc'
|
||||
|
||||
|
||||
# -- Options for LaTeX output --------------------------------------------------
|
||||
|
|
@ -177,7 +177,7 @@ htmlhelp_basename = 'zambonidoc'
|
|||
# Grouping the document tree into LaTeX files. List of tuples
|
||||
# (source start file, target name, title, author, documentclass [howto/manual]).
|
||||
latex_documents = [
|
||||
('index', 'zamboni.tex', u'zamboni Documentation',
|
||||
('index', 'olympia.tex', u'olympia Documentation',
|
||||
u'Jeff Balogh', 'manual'),
|
||||
]
|
||||
|
||||
|
|
@ -211,4 +211,4 @@ for key, val in intersphinx_mapping.items():
|
|||
intersphinx_mapping[key] = '_intersphinx/' + val
|
||||
|
||||
# Root url where source files can be browsed online.
|
||||
src_base_url = 'http://github.com/mozilla/zamboni/tree/master/'
|
||||
src_base_url = 'http://github.com/mozilla/olympia/tree/master/'
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
===================================
|
||||
Welcome to Zamboni's documentation!
|
||||
Welcome to Olympia's documentation!
|
||||
===================================
|
||||
|
||||
Zamboni is the codebase for https://addons.mozilla.org/ and
|
||||
https://marketplace.firefox.com/ ; the source lives at https://github.com/mozilla/zamboni
|
||||
Olympia is the codebase for https://addons.mozilla.org/ ;
|
||||
the source lives at https://github.com/mozilla/olympia
|
||||
|
||||
If you want to build a completely different site with all the same Django
|
||||
optimizations for security, scalability, L10n, and ease of use, check out
|
||||
|
|
@ -12,7 +12,7 @@ Mozilla's `Playdoh starter kit <http://playdoh.readthedocs.org/>`_.
|
|||
|
||||
Installation
|
||||
------------
|
||||
What are you waiting for?! :ref:`Install Zamboni! <installation>`
|
||||
What are you waiting for?! :ref:`Install Olympia! <installation>`
|
||||
|
||||
|
||||
Contents
|
||||
|
|
@ -21,7 +21,7 @@ Contents
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
topics/install-zamboni/index
|
||||
topics/install-olympia/index
|
||||
topics/hacking/index
|
||||
|
||||
.. toctree::
|
||||
|
|
|
|||
|
|
@ -28,14 +28,14 @@ INSTALLED_APPS += (
|
|||
CACHES = {
|
||||
'default': {
|
||||
'BACKEND': 'caching.backends.locmem.LocMemCache',
|
||||
'LOCATION': 'zamboni',
|
||||
'LOCATION': 'olympia',
|
||||
}
|
||||
}
|
||||
# Caching is required for CSRF to work, please do not use the dummy cache.
|
||||
|
||||
DATABASES = {
|
||||
'default': {
|
||||
'NAME': 'zamboni',
|
||||
'NAME': 'olympia',
|
||||
'ENGINE': 'django.db.backends.mysql',
|
||||
'USER': 'root',
|
||||
'PASSWORD': '',
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ TEMPLATE_DEBUG = False
|
|||
# The default database should point to the master.
|
||||
DATABASES = {
|
||||
'default': {
|
||||
'NAME': 'zamboni',
|
||||
'NAME': 'olympia',
|
||||
'ENGINE': 'django.db.backends.mysql',
|
||||
'HOST': '',
|
||||
'PORT': '',
|
||||
|
|
@ -15,7 +15,7 @@ DATABASES = {
|
|||
'OPTIONS': {'init_command': 'SET storage_engine=InnoDB'},
|
||||
},
|
||||
'slave': {
|
||||
'NAME': 'zamboni',
|
||||
'NAME': 'olympia',
|
||||
'ENGINE': 'django.db.backends.mysql',
|
||||
'HOST': '',
|
||||
'PORT': '',
|
||||
|
|
@ -49,7 +49,7 @@ DEBUG_PROPAGATE_EXCEPTIONS = DEBUG
|
|||
# lib/settings_base.py.
|
||||
|
||||
# HEKA_CONF = {
|
||||
# 'logger': 'zamboni',
|
||||
# 'logger': 'olympia',
|
||||
# 'stream': {
|
||||
# 'class': 'heka.streams.UdpStream',
|
||||
# 'host': ['10.0.1.5', '10.0.1.10']
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
.. _api:
|
||||
|
||||
===============
|
||||
Marketplace API
|
||||
===============
|
||||
|
||||
.. include:: api/moved.rst
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
.. _misc:
|
||||
|
||||
=============
|
||||
Miscellaneous
|
||||
=============
|
||||
|
||||
.. include:: moved.rst
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
.. note:: The Marketplace API docs have a new home! Check them out at
|
||||
http://firefox-marketplace-api.readthedocs.org
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
.. _payment:
|
||||
|
||||
========
|
||||
Payments
|
||||
========
|
||||
|
||||
.. include:: moved.rst
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
.. _ratings:
|
||||
|
||||
=======
|
||||
Ratings
|
||||
=======
|
||||
|
||||
.. include:: moved.rst
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
.. _reviewers:
|
||||
|
||||
=========
|
||||
Reviewers
|
||||
=========
|
||||
|
||||
.. include:: moved.rst
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
.. _search:
|
||||
|
||||
======
|
||||
Search
|
||||
======
|
||||
|
||||
.. include:: moved.rst
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
.. _submission:
|
||||
|
||||
==========
|
||||
Submission
|
||||
==========
|
||||
|
||||
.. include:: moved.rst
|
||||
|
|
@ -23,5 +23,5 @@ but to use a merge commit if you have multiple commits that form a cohesive unit
|
|||
|
||||
Here are some tips on `Using topic branches and interactive rebasing effectively <http://blog.mozilla.com/webdev/2011/11/21/git-using-topic-branches-and-interactive-rebasing-effectively/>`_.
|
||||
|
||||
.. _master: http://github.com/mozilla/zamboni/tree/master
|
||||
.. _master: http://github.com/mozilla/olympia/tree/master
|
||||
.. _waffle: https://github.com/jsocol/django-waffle
|
||||
|
|
|
|||
|
|
@ -16,16 +16,16 @@ The Perfect Git Configuration
|
|||
|
||||
We're going to talk about two git repositories:
|
||||
|
||||
* *origin* will be the main zamboni repo at http://github.com/mozilla/zamboni.
|
||||
* *mine* will be your fork at http://github.com/:user/zamboni.
|
||||
* *origin* will be the main olympia repo at http://github.com/mozilla/olympia.
|
||||
* *mine* will be your fork at http://github.com/:user/olympia.
|
||||
|
||||
There should be something like this in your ``.git/config`` already::
|
||||
|
||||
[remote "origin"]
|
||||
url = git://github.com/mozilla/zamboni.git
|
||||
url = git://github.com/mozilla/olympia.git
|
||||
fetch = +refs/heads/*:refs/remotes/origin/*
|
||||
|
||||
Now we'll set up your master to pull directly from the upstream zamboni::
|
||||
Now we'll set up your master to pull directly from the upstream olympia::
|
||||
|
||||
[branch "master"]
|
||||
remote = origin
|
||||
|
|
@ -38,7 +38,7 @@ often easier.
|
|||
|
||||
After you've forked the repository on github, tell git about your new repo::
|
||||
|
||||
git remote add -f mine git@github.com:user/zamboni.git
|
||||
git remote add -f mine git@github.com:user/olympia.git
|
||||
|
||||
Make sure to replace *user* with your name.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
Style Guide
|
||||
===================
|
||||
|
||||
Writing code for zamboni? Awesome! Please help keep our code readable by,
|
||||
Writing code for olympia? Awesome! Please help keep our code readable by,
|
||||
whenever possible, adhering to these style conventions.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -16,8 +16,8 @@ Configuration
|
|||
Configuration for your unit tests is mostly handled automatically. The only
|
||||
thing you'll need to ensure is that the database credentials in your
|
||||
``settings_local.py`` has full permissions to modify a database with ``test-``
|
||||
prepended to it. For example, if my database name were ``zamboni`` this
|
||||
database would be ``test-zamboni``.
|
||||
prepended to it. For example, if my database name were ``olympia`` this
|
||||
database would be ``test_olympia``.
|
||||
|
||||
Running Tests
|
||||
-------------
|
||||
|
|
@ -58,7 +58,7 @@ To fail and stop running tests on the first failure::
|
|||
If you wish to add arguments, or run a specific test, overload the variables
|
||||
(check the Makefile for more information)::
|
||||
|
||||
make SETTINGS=settings_mkt ARGS='--verbosity 2 zamboni.apps.amo.tests.test_url_prefix:MiddlewareTest.test_get_app' test
|
||||
make SETTINGS=settings_mkt ARGS='--verbosity 2 olympia.apps.amo.tests.test_url_prefix:MiddlewareTest.test_get_app' test
|
||||
|
||||
Those targets include some useful options, like the ``--with-id`` which allows
|
||||
you to re-run only the tests failed from the previous run::
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ Redis
|
|||
-----
|
||||
|
||||
On OS X the package is called ``redis``. Get it running with the ``launchctl``
|
||||
script included in homebrew. To let zamboni know about Redis, add this to
|
||||
script included in homebrew. To let olympia know about Redis, add this to
|
||||
``settings_local.py``::
|
||||
|
||||
CACHE_MACHINE_USE_REDIS = True
|
||||
|
|
@ -117,7 +117,7 @@ Stylus CSS
|
|||
|
||||
Learn about Stylus at http://learnboost.github.com/stylus/ ::
|
||||
|
||||
cd zamboni
|
||||
cd olympia
|
||||
npm install
|
||||
|
||||
In your ``settings_local.py`` (or ``settings_local_mkt.py``) ensure you are
|
||||
|
|
@ -46,9 +46,9 @@ Then run the following commands: ::
|
|||
sudo rabbitmq-server -detached
|
||||
|
||||
# Setup rabitty things (sudo is required to read the cookie file)
|
||||
sudo rabbitmqctl add_user zamboni zamboni
|
||||
sudo rabbitmqctl add_vhost zamboni
|
||||
sudo rabbitmqctl set_permissions -p zamboni zamboni ".*" ".*" ".*"
|
||||
sudo rabbitmqctl add_user olympia olympia
|
||||
sudo rabbitmqctl add_vhost olympia
|
||||
sudo rabbitmqctl set_permissions -p olympia olympia ".*" ".*" ".*"
|
||||
|
||||
Back in safe and happy django-land you should be able to run: ::
|
||||
|
||||
|
|
@ -95,7 +95,7 @@ All the Addons with ids in ``pks`` will (eventually) have their
|
|||
Cron Jobs
|
||||
~~~~~~~~~
|
||||
|
||||
This is all good, but let's automate this. In Zamboni we can create cron
|
||||
This is all good, but let's automate this. In Olympia we can create cron
|
||||
jobs like so: ::
|
||||
|
||||
@cronjobs.register
|
||||
|
|
@ -60,7 +60,7 @@ Launch the Elasticsearch service. If you used homebrew, ``brew info
|
|||
elasticsearch`` will show you the commands to launch. If you used aptitude,
|
||||
Elasticsearch will come with a start-stop daemon in /etc/init.d.
|
||||
|
||||
Zamboni has commands that sets up mappings and indexes objects such as add-ons
|
||||
Olympia has commands that sets up mappings and indexes objects such as add-ons
|
||||
and apps for you. Setting up the mappings is analagous to defining the
|
||||
structure of a table, indexing is analagous to storing rows.
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ If you need to use another settings file and add arguments::
|
|||
Indexing
|
||||
--------
|
||||
|
||||
Zamboni has other indexing commands. It is worth noting that the index is
|
||||
Olympia has other indexing commands. It is worth noting that the index is
|
||||
maintained incrementally through post_save and post_delete hooks::
|
||||
|
||||
./manage.py cron reindex_addons # Index all the add-ons.
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
===============
|
||||
Install Zamboni
|
||||
Install Olympia
|
||||
===============
|
||||
|
||||
.. toctree::
|
||||
|
|
@ -3,7 +3,7 @@
|
|||
Installing In A VM With Vagrant
|
||||
===============================
|
||||
|
||||
Instead of :doc:`installing Zamboni piecemeal <installation>` you can set it up
|
||||
Instead of :doc:`installing Olympia piecemeal <installation>` you can set it up
|
||||
in a virtual machine. This is an ideal way to get up and running quickly and to
|
||||
keep your dev system clean. At the time of this writing there are a few
|
||||
outstanding Vagrant / VirtualBox bugs that have blocked some people. But if it
|
||||
|
|
@ -43,20 +43,20 @@ If you get stuck, see the Troubleshooting section below.
|
|||
Get The Source
|
||||
--------------
|
||||
|
||||
Clone the Zamboni repository::
|
||||
Clone the Olympia repository::
|
||||
|
||||
cd ~
|
||||
git clone --recursive git://github.com/mozilla/zamboni.git
|
||||
git clone --recursive git://github.com/mozilla/olympia.git
|
||||
|
||||
This takes about a minute and puts the source code in a directory called
|
||||
``zamboni``.
|
||||
``olympia``.
|
||||
|
||||
Build the VM
|
||||
------------
|
||||
|
||||
Change into the source code directory and start the VM with vagrant::
|
||||
|
||||
cd zamboni
|
||||
cd olympia
|
||||
vagrant up
|
||||
|
||||
After about 5-10 minutes, depending on your Internet connection, vagrant
|
||||
|
|
@ -88,7 +88,7 @@ Suspending/Resuming the VM
|
|||
|
||||
To conserve system resources you can suspend the VM like::
|
||||
|
||||
cd zamboni
|
||||
cd olympia
|
||||
vagrant suspend
|
||||
|
||||
Then when you want to use it again just type::
|
||||
|
|
@ -98,12 +98,12 @@ Then when you want to use it again just type::
|
|||
This boots up the VM in the state it was left in but you still have to SSH in
|
||||
and start up the dev server with the command above.
|
||||
|
||||
Updating Zamboni Code
|
||||
Updating Olympia Code
|
||||
---------------------
|
||||
|
||||
To sync your repository with upstream changes, just update the code using git::
|
||||
|
||||
cd zamboni
|
||||
cd olympia
|
||||
git pull && git submodule sync --quiet && git submodule update --init --recursive
|
||||
|
||||
Next, rebuild your VM so that any new requirements are installed and any new
|
||||
|
|
@ -116,7 +116,7 @@ You can re-run all installation steps with the reload command. If a package is
|
|||
already installed in the VM it will not be re-installed (so it's a bit faster).
|
||||
::
|
||||
|
||||
cd zamboni
|
||||
cd olympia
|
||||
vagrant reload
|
||||
|
||||
However, it may not always work. To completely destroy your VM and start from
|
||||
|
|
@ -146,10 +146,10 @@ Your ``custom.pp`` file is ignored by git.
|
|||
Troubleshooting
|
||||
---------------
|
||||
|
||||
If you have already set up Zamboni with a custom ``settings_local.py`` file
|
||||
If you have already set up Olympia with a custom ``settings_local.py`` file
|
||||
then be sure your database credentials match the defaults::
|
||||
|
||||
'NAME': 'zamboni',
|
||||
'NAME': 'olympia',
|
||||
'USER': 'root',
|
||||
'PASSWORD': '',
|
||||
...
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
.. _installation:
|
||||
|
||||
==================
|
||||
Installing Zamboni
|
||||
Installing Olympia
|
||||
==================
|
||||
|
||||
We're going to use all the hottest tools to set up a nice environment. Skip
|
||||
|
|
@ -9,10 +9,10 @@ steps at your own peril. Here we go!
|
|||
|
||||
.. note::
|
||||
|
||||
For less manual work, you can build Zamboni in a
|
||||
It was once possible to build Olympia in a
|
||||
:doc:`virtual machine using vagrant <install-with-vagrant>`
|
||||
but that has known bugs at the time of this writing.
|
||||
For best results, install manually.
|
||||
For best results, install manually or contribute to 956815!
|
||||
|
||||
|
||||
Requirements
|
||||
|
|
@ -54,7 +54,7 @@ On OS X
|
|||
~~~~~~~
|
||||
The best solution for installing UNIX tools on OS X is Homebrew_.
|
||||
|
||||
The following packages will get you set for zamboni::
|
||||
The following packages will get you set for olympia::
|
||||
|
||||
brew install python libxml2 mysql libmemcached openssl swig jpeg
|
||||
|
||||
|
|
@ -68,12 +68,12 @@ You'll probably need to :ref:`configure MySQL after install <configure-mysql>`
|
|||
Use the Source
|
||||
--------------
|
||||
|
||||
Grab zamboni from github with::
|
||||
Grab olympia from github with::
|
||||
|
||||
git clone --recursive git://github.com/mozilla/zamboni.git
|
||||
cd zamboni
|
||||
git clone --recursive git://github.com/mozilla/olympia.git
|
||||
cd olympia
|
||||
|
||||
``zamboni.git`` is all the source code. :ref:`updating` is detailed later on.
|
||||
``olympia.git`` is all the source code. :ref:`updating` is detailed later on.
|
||||
|
||||
If at any point you realize you forgot to clone with the recursive
|
||||
flag, you can fix that by running::
|
||||
|
|
@ -85,7 +85,7 @@ virtualenv and virtualenvwrapper
|
|||
--------------------------------
|
||||
|
||||
`virtualenv`_ is a tool to create
|
||||
isolated Python environments. This will let you put all of Zamboni's
|
||||
isolated Python environments. This will let you put all of Olympia's
|
||||
dependencies in a single directory rather than your global Python directory.
|
||||
For ultimate convenience, we'll also use `virtualenvwrapper`_
|
||||
which adds commands to your shell.
|
||||
|
|
@ -109,8 +109,8 @@ virtualenvwrapper Hooks (optional)
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
virtualenvwrapper lets you run hooks when creating, activating, and deleting
|
||||
virtual environments. These hooks can change settings, the shell environment,
|
||||
or anything else you want to do from a shell script. For complete hook
|
||||
virtual environments. These hooks can change settings, the shell environment,
|
||||
or anything else you want to do from a shell script. For complete hook
|
||||
documentation, see
|
||||
http://www.doughellmann.com/docs/virtualenvwrapper/hooks.html.
|
||||
|
||||
|
|
@ -122,29 +122,29 @@ above), and ``premkvirtualenv`` should be made executable.
|
|||
Getting Packages
|
||||
----------------
|
||||
|
||||
Now we're ready to go, so create an environment for zamboni::
|
||||
Now we're ready to go, so create an environment for olympia::
|
||||
|
||||
mkvirtualenv --python=python2.6 zamboni
|
||||
mkvirtualenv --python=python2.6 olympia
|
||||
|
||||
That creates a clean environment named zamboni using Python 2.6. You can get
|
||||
That creates a clean environment named olympia using Python 2.6. You can get
|
||||
out of the environment by restarting your shell or calling ``deactivate``.
|
||||
|
||||
To get back into the zamboni environment later, type::
|
||||
To get back into the olympia environment later, type::
|
||||
|
||||
workon zamboni # requires virtualenvwrapper
|
||||
workon olympia # requires virtualenvwrapper
|
||||
|
||||
.. note:: Zamboni requires at least Python 2.6.1, production is using
|
||||
.. note:: Olympia requires at least Python 2.6.1, production is using
|
||||
Python 2.6.6. Python 2.7 is not supported.
|
||||
|
||||
.. note:: If you want to use a different Python binary, pass the name (if it is
|
||||
on your path) or the full path to mkvirtualenv with ``--python``::
|
||||
|
||||
mkvirtualenv --python=/usr/local/bin/python2.6 zamboni
|
||||
mkvirtualenv --python=/usr/local/bin/python2.6 olympia
|
||||
|
||||
.. note:: If you are using an older version of virtualenv that defaults to
|
||||
using system packages you might need to pass ``--no-site-packages``::
|
||||
|
||||
mkvirtualenv --python=python2.6 --no-site-packages zamboni
|
||||
mkvirtualenv --python=python2.6 --no-site-packages olympia
|
||||
|
||||
Finish the install
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -200,17 +200,12 @@ It may be because of a `few reasons`_:
|
|||
Settings
|
||||
--------
|
||||
|
||||
.. note::
|
||||
|
||||
Also see the Multiple Sites section below for using settings files to run
|
||||
the Add-ons and Marketplace sites side by side.
|
||||
|
||||
.. note::
|
||||
|
||||
There is a :doc:`settings-changelog`, this can be useful for people who are already
|
||||
setup but want to know what has recently changed.
|
||||
|
||||
Most of zamboni is already configured in ``settings.py``, but there's some
|
||||
Most of olympia is already configured in ``settings.py``, but there's some
|
||||
things you need to configure locally. All your local settings go into
|
||||
``settings_local.py``. The settings template for
|
||||
developers, included below, is at :src:`docs/settings/settings_local.dev.py`.
|
||||
|
|
@ -237,7 +232,7 @@ https://landfill.addons.allizom.org/db/
|
|||
There is a management command that download and install the landfill
|
||||
database. You have to create the database first using the following
|
||||
command filling in the database name from your ``settings_local.py``
|
||||
(Defaults to ``zamboni``)::
|
||||
(Defaults to ``olympia``)::
|
||||
|
||||
mysqladmin -uroot create $DB_NAME
|
||||
|
||||
|
|
@ -250,8 +245,8 @@ base landfill database::
|
|||
Here are the shell commands to pull down and set up the latest
|
||||
snapshot manually (ie without the management command)::
|
||||
|
||||
export DB_NAME=zamboni
|
||||
export DB_USER=zamboni
|
||||
export DB_NAME=olympia
|
||||
export DB_USER=olympia
|
||||
mysqladmin -uroot create $DB_NAME
|
||||
mysql -uroot -B -e'GRANT ALL PRIVILEGES ON $DB_NAME.* TO $DB_USER@localhost'
|
||||
wget --no-check-certificate -P /tmp https://landfill.addons.allizom.org/db/landfill-`date +%Y-%m-%d`.sql.gz
|
||||
|
|
@ -282,47 +277,16 @@ migrations like this::
|
|||
More info on schematic: https://github.com/mozilla/schematic
|
||||
|
||||
|
||||
Multiple sites
|
||||
--------------
|
||||
|
||||
We now run multiple sites off the zamboni code base. The current sites are:
|
||||
|
||||
- *default* the Add-ons site at https://addons.mozilla.org/
|
||||
|
||||
- *mkt* the Firefox Marketplace at https://marketplace.firefox.com/
|
||||
|
||||
There are modules in zamboni for each of these base settings to make minor
|
||||
modifications to settings, url, templates and so on. Start by copying the
|
||||
template from ``docs/settings/settings_local.dev.py`` into a custom file.
|
||||
|
||||
To run the Add-ons site, make a ``settings_local_amo.py`` file with this import
|
||||
header::
|
||||
|
||||
from default.settings import *
|
||||
|
||||
Or to run the Marketplace site, make a ``settings_local_mkt.py`` file with
|
||||
these imports::
|
||||
|
||||
from mkt.settings import *
|
||||
|
||||
|
||||
Run the Server
|
||||
--------------
|
||||
|
||||
If you've gotten the system requirements, downloaded ``zamboni`` and
|
||||
If you've gotten the system requirements, downloaded ``olympia`` and
|
||||
``zamboni-lib``, set up your virtualenv with the compiled packages, and
|
||||
configured your settings and database, you're good to go.
|
||||
|
||||
To choose which site you want to run, use the `settings` command line
|
||||
argument to pass in a local settings file you created above.
|
||||
|
||||
|
||||
Run The Add-ons Server
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
./manage.py runserver --settings=settings_local_amo 0.0.0.0:8000
|
||||
./manage.py runserver --settings=settings_local 0.0.0.0:8000
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -339,15 +303,6 @@ Run The Add-ons Server
|
|||
those will be compiled on the fly by the LESS javascript compiler.
|
||||
|
||||
|
||||
Run The Marketplace Server
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
./manage.py runserver --settings=settings_local_mkt 0.0.0.0:8000
|
||||
|
||||
|
||||
|
||||
Persona
|
||||
-------
|
||||
|
||||
|
|
@ -389,34 +344,13 @@ on the login screen then go back to the shell you started your dev server in.
|
|||
You'll see the email message with the password reset link in stdout.
|
||||
|
||||
|
||||
Setting Up the Front End
|
||||
------------------------
|
||||
|
||||
To add the code from all front-end dependencies, you can simply run::
|
||||
|
||||
commonplace fiddle
|
||||
|
||||
Commonplace is a set of CLI tools that will handle cloning and updating front-
|
||||
end dependencies. This is done automatically if you use the ``make update_mkt``
|
||||
command. More information on how this command works is available in the
|
||||
`Commonplace wiki <https://github.com/mozilla/commonplace/wiki/CLI-Tools#fiddle>`_
|
||||
|
||||
Each of our front-end projects live in their own repositories. These are
|
||||
single-page apps that talk to the APIs in Zamboni. Commonplace serves as the
|
||||
glue which brings theem together and keeps them running in sync.
|
||||
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
The :ref:`testing` page has more info, but here's the quick way to run
|
||||
zamboni's marketplace tests::
|
||||
olympia's tests::
|
||||
|
||||
./manage.py test --settings=settings_local_mkt
|
||||
|
||||
Or to run AMO's tests::
|
||||
|
||||
./manage.py test --settings=settings_local_amo
|
||||
./manage.py test --settings=settings_local
|
||||
|
||||
There are a few useful makefile targets that you can use, the simplest one
|
||||
being::
|
||||
|
|
@ -432,7 +366,7 @@ the other available targets.
|
|||
Updating
|
||||
--------
|
||||
|
||||
To run a full update of zamboni (including source files, pip requirements and
|
||||
To run a full update of olympia (including source files, pip requirements and
|
||||
database migrations)::
|
||||
|
||||
make update
|
||||
|
|
@ -444,7 +378,7 @@ landfill::
|
|||
|
||||
If you want to do it manually, then check the following steps:
|
||||
|
||||
This updates zamboni::
|
||||
This updates olympia::
|
||||
|
||||
git checkout master && git pull && git submodule update --init --recursive
|
||||
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
.. _packages:
|
||||
|
||||
====================
|
||||
Packaging in Olympia
|
||||
====================
|
||||
|
||||
There are two ways of getting packages for olympia. The first is to install
|
||||
everything using pip. We have our packages separated into three files:
|
||||
|
||||
:src:`requirements/compiled.txt`
|
||||
All packages that require (or go faster with) compilation. These can't be
|
||||
distributed cross-platform, so they need to be installed through your
|
||||
system's package manager or pip.
|
||||
|
||||
:src:`requirements/prod.txt`
|
||||
The minimal set of packages you need to run olympia in production. You
|
||||
also need to get ``requirements/compiled.txt``.
|
||||
|
||||
:src:`requirements/dev.txt`
|
||||
All the packages needed for running tests and development servers. This
|
||||
automatically includes ``requirements/prod.txt``.
|
||||
|
||||
|
||||
Installing through pip
|
||||
----------------------
|
||||
|
||||
You can get a development environment with ::
|
||||
|
||||
pip install --no-deps -r requirements/dev.txt
|
||||
|
|
@ -14,7 +14,7 @@ ____________________________
|
|||
|
||||
First look for the following image serving settings::
|
||||
|
||||
SERVE_TMP_PATH = True # maps /tmp to zamboni/tmp
|
||||
SERVE_TMP_PATH = True # maps /tmp to olympia/tmp
|
||||
PREVIEW_THUMBNAIL_URL = '/tmp/uploads/previews/thumbs/%s/%d.png?modified=%d'
|
||||
PREVIEW_FULL_URL = '/tmp/uploads/previews/full/%s/%d.png?modified=%d'
|
||||
USERPICS_URL = '/tmp/uploads/userpics/%s/%s/%s.png?modified=%d'
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
Get Started With Vagrant On Windows
|
||||
===================================
|
||||
|
||||
Here is a guide to help you get started installing Zamboni inside a vagrant virtual machine on Windows. Once you're done, you can go back to :doc:`installing Zamboni with vagrant <install-with-vagrant>`.
|
||||
Here is a guide to help you get started installing Olympia inside a vagrant virtual machine on Windows. Once you're done, you can go back to :doc:`installing Olympia with vagrant <install-with-vagrant>`.
|
||||
|
||||
Install Virtual Box
|
||||
===================
|
||||
|
|
@ -50,14 +50,14 @@ Run the command ``gem install vagrant``
|
|||
|
||||
If you are running 64bit Windows you MUST use v0.9.6 or above otherwise Virtual Box will not be detected properly.
|
||||
|
||||
Get Zamboni Code
|
||||
Get Olympia Code
|
||||
================
|
||||
|
||||
cd to the folder above where you want the zamboni folder and files to be placed (e.g. ``c:\``)
|
||||
Run the command ``git clone --recursive git://github.com/mozilla/zamboni.git``
|
||||
cd to the folder above where you want the olympia folder and files to be placed (e.g. ``c:\``)
|
||||
Run the command ``git clone --recursive git://github.com/mozilla/olympia.git``
|
||||
This will take some time, go get a cup of coffee, eat lunch, go for a walk, etc.
|
||||
|
||||
In the zamboni folder (e.g. ``c:\zamboni``) find the file ``Vagrantfile`` and open it in your favorite text editor.
|
||||
In the olympia folder (e.g. ``c:\olympia``) find the file ``Vagrantfile`` and open it in your favorite text editor.
|
||||
|
||||
Look for the following lines::
|
||||
|
||||
|
|
@ -72,10 +72,10 @@ Change them to::
|
|||
config.vm.network :hostonly, "33.33.33.24"
|
||||
#config.vm.network "33.33.33.24" # old 0.8.* way
|
||||
|
||||
Start The Zamboni VM
|
||||
Start The Olympia VM
|
||||
====================
|
||||
|
||||
It is time to build your zamboni virtual machine. In the command prompt, cd to the zamboni folder (e.g. cd ``c:\zamboni``) and run the command ``vagrant up``. This step will download the zamboni virtual machine from Mozilla and install it. Before warned that this archive is many hundred megabytes in size so it will take some time to download even if you are on a broadband connection.
|
||||
It is time to build your olympia virtual machine. In the command prompt, cd to the olympia folder (e.g. cd ``c:\olympia``) and run the command ``vagrant up``. This step will download the olympia virtual machine from Mozilla and install it. Before warned that this archive is many hundred megabytes in size so it will take some time to download even if you are on a broadband connection.
|
||||
|
||||
Configure SSH
|
||||
~~~~~~~~~~~~~
|
||||
|
|
@ -84,13 +84,13 @@ Download PuTTY SSH client and PuTTYgen from http://www.chiark.greenend.org.uk/~s
|
|||
|
||||
You need to generate a private key for PuTTY. To do this, launch PuTTYgen and click on the "generate" button. You will be instructed to randomly move your mouse around the PuTTYgen window to generate the key. Once this is done, click on "load" and find the file "insecure_private_key", it will probably be in your user folder under ".vagrant.d" (e.g. on Win7 at ``C:\Users\{your username}\.vagrant.d``). Now save your public key and then save your private key (use different file names for each).
|
||||
|
||||
Create a PuTTY SSH session for zamboni. Launch PuTTY. In the host name put "127.0.0.1" and in the port use "2222". In the category pane find "data" under "connection" and place "vagrant" in the auto-login username field. Then expand out the "SSH" branch and select "auth". Next to the "private key file for authentication" field click on browse and find the private key you just generated. Select it and click "open" in the folder browser window. Now go back to "session" in the category pane in PuTTY, add "vagrant" to the saved sessions field and then click "save". This will save your session for future use.
|
||||
Create a PuTTY SSH session for olympia. Launch PuTTY. In the host name put "127.0.0.1" and in the port use "2222". In the category pane find "data" under "connection" and place "vagrant" in the auto-login username field. Then expand out the "SSH" branch and select "auth". Next to the "private key file for authentication" field click on browse and find the private key you just generated. Select it and click "open" in the folder browser window. Now go back to "session" in the category pane in PuTTY, add "vagrant" to the saved sessions field and then click "save". This will save your session for future use.
|
||||
|
||||
Login to zamboni by clicking on "open" in the PuTTY window. This should automatically log you into the Zamboni VM. If you add the PuTTY file path to your system properties environment variable "path" (e.g. ``;C:\Program Files (x86)\Putty``) you should be able to reference PuTTY from the command prompt by simply calling "putty -load vagrant" once you reboot your computer.
|
||||
Login to olympia by clicking on "open" in the PuTTY window. This should automatically log you into the Olympia VM. If you add the PuTTY file path to your system properties environment variable "path" (e.g. ``;C:\Program Files (x86)\Putty``) you should be able to reference PuTTY from the command prompt by simply calling "putty -load vagrant" once you reboot your computer.
|
||||
|
||||
The first time you log into Zamboni you should see a very long series of scrolling text with lots of SQL statements etc. This is the database migrations taking place. This phase could take quite a while to complete. Don't do anything to your PuTTY VM session until it gives you back a command prompt.
|
||||
The first time you log into Olympia you should see a very long series of scrolling text with lots of SQL statements etc. This is the database migrations taking place. This phase could take quite a while to complete. Don't do anything to your PuTTY VM session until it gives you back a command prompt.
|
||||
|
||||
Congratulations if things went well your Zamboni VM is up and running. You are now ready to start the Dev Server.
|
||||
Congratulations if things went well your Olympia VM is up and running. You are now ready to start the Dev Server.
|
||||
|
||||
Start the Dev Server
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -99,4 +99,4 @@ From PuTTY VM session, enter the command ``./project/vagrant/bin/start.sh``.
|
|||
|
||||
You should now be able to access your development server on a special IP address set up by Vagrant. Point your web browser to http://33.33.33.24:8000/
|
||||
|
||||
More info on :doc:`installing Zamboni with vagrant <install-with-vagrant>`.
|
||||
More info on :doc:`installing Olympia with vagrant <install-with-vagrant>`.
|
||||
|
|
@ -1,93 +0,0 @@
|
|||
.. _packages:
|
||||
|
||||
====================
|
||||
Packaging in Zamboni
|
||||
====================
|
||||
|
||||
There are two ways of getting packages for zamboni. The first is to install
|
||||
everything using pip. We have our packages separated into three files:
|
||||
|
||||
:src:`requirements/compiled.txt`
|
||||
All packages that require (or go faster with) compilation. These can't be
|
||||
distributed cross-platform, so they need to be installed through your
|
||||
system's package manager or pip.
|
||||
|
||||
:src:`requirements/prod.txt`
|
||||
The minimal set of packages you need to run zamboni in production. You
|
||||
also need to get ``requirements/compiled.txt``.
|
||||
|
||||
:src:`requirements/dev.txt`
|
||||
All the packages needed for running tests and development servers. This
|
||||
automatically includes ``requirements/prod.txt``.
|
||||
|
||||
|
||||
Installing through pip
|
||||
----------------------
|
||||
|
||||
You can get a development environment with ::
|
||||
|
||||
pip install --no-deps -r requirements/dev.txt
|
||||
|
||||
|
||||
Using the vendor library
|
||||
------------------------
|
||||
|
||||
**Note**: this is deprecated, all packages should be added in requirements.
|
||||
|
||||
The other method is to use the /vendor library of all packages and
|
||||
repositories. These are maintained by Hudson in the zamboni-lib repository.
|
||||
|
||||
Check out the vendor lib with ::
|
||||
|
||||
git clone --recursive git://github.com/mozilla/zamboni-lib.git ./vendor
|
||||
|
||||
Once the zamboni-lib repo has been downloaded to ``/vendor``, you only need to
|
||||
install the compiled packages. These can come from your system package manager
|
||||
or from ::
|
||||
|
||||
pip install -r requirements/compiled.txt
|
||||
|
||||
|
||||
Adding new packages
|
||||
-------------------
|
||||
|
||||
**Note**: this is deprecated, all packages should be added in requirements.
|
||||
|
||||
The vendor repo was seeded with ::
|
||||
|
||||
pip install --no-install --build=vendor/packages --src=vendor/src -I -r requirements/dev.txt
|
||||
|
||||
Then I added everything in ``/packages`` and set up submodules in ``/src`` (see
|
||||
below). We'll be keeping this up to date through Hudson, but if you add new
|
||||
packages you should seed them yourself.
|
||||
|
||||
If we wanted to add a new dependency called ``cheeseballs`` to zamboni, you
|
||||
would add it to ``requirements/prod.txt`` or ``requirements/dev.txt`` and then
|
||||
do ::
|
||||
|
||||
pip install --no-install --build=vendor/packages --src=vendor/src -I cheeseballs
|
||||
|
||||
Then you need to update ``vendor/zamboni.pth``. Python uses ``.pth`` files to
|
||||
dynamically add directories to ``sys.path``
|
||||
(`docs <http://docs.python.org/library/site.html>`_).
|
||||
|
||||
I created ``zamboni.pth`` with this::
|
||||
|
||||
find packages src -type d -depth 1 > zamboni.pth
|
||||
|
||||
``html5lib`` and ``selenium`` are troublesome, so they need to be sourced with
|
||||
``packages/html5lib/src`` and ``packages/selenium/src``. Hopefully you won't
|
||||
hit any snags like that.
|
||||
|
||||
|
||||
Adding submodules
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
**Note**: this is deprecated, all packages should be added in requirements.
|
||||
|
||||
::
|
||||
|
||||
for f in src/*
|
||||
pushd $f >/dev/null && REPO=$(git config remote.origin.url) && popd > /dev/null && git submodule add $REPO $f
|
||||
|
||||
Holy readability batman!
|
||||
|
|
@ -16,7 +16,7 @@ production, we're piping everything into ``syslog``.
|
|||
Configuration
|
||||
-------------
|
||||
|
||||
The root logger is set up from ``log_settings.py`` in the base of zamboni's
|
||||
The root logger is set up from ``log_settings.py`` in the base of olympia's
|
||||
tree. It sets up sensible defaults, but you can twiddle with these settings:
|
||||
|
||||
``LOG_LEVEL``
|
||||
|
|
@ -65,7 +65,7 @@ Using Loggers
|
|||
The ``logging`` package uses global objects to make the same logging
|
||||
configuration available to all code loaded in the interpreter. Loggers are
|
||||
created in a pseudo-namespace structure, so app-level loggers can inherit
|
||||
settings from a root logger. zamboni's root namespace is just ``"z"``, in the
|
||||
settings from a root logger. olympia's root namespace is just ``"z"``, in the
|
||||
interest of brevity. In the caching package, we create a logger that inherits
|
||||
the configuration by naming it ``"z.caching"``::
|
||||
|
||||
|
|
@ -76,7 +76,7 @@ the configuration by naming it ``"z.caching"``::
|
|||
log.debug("I'm in the caching package.")
|
||||
|
||||
Logs can be nested as much as you want. Maintaining log namespaces is useful
|
||||
because we can turn up the logging output for a particular section of zamboni
|
||||
because we can turn up the logging output for a particular section of olympia
|
||||
without becoming overwhelmed with logging from all other parts.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,74 +0,0 @@
|
|||
.. _payments:
|
||||
|
||||
========================================
|
||||
Setting Up Payments for Apps and Add-ons
|
||||
========================================
|
||||
|
||||
Add-on PayPal Sandbox Settings
|
||||
==============================
|
||||
|
||||
Add-ons on AMO can accept contributions. Those contributions would run through
|
||||
PayPal.
|
||||
|
||||
Add these URLs to your local settings to use the sandbox::
|
||||
|
||||
PAYPAL_API_URL = 'https://api-3t.sandbox.paypal.com/nvp'
|
||||
PAYPAL_FLOW_URL = 'https://sandbox.paypal.com/webapps/adaptivepayment/flow/pay'
|
||||
PAYPAL_PAY_URL = 'https://svcs.sandbox.paypal.com/AdaptivePayments/'
|
||||
PAYPAL_CGI_URL = 'https://www.sandbox.paypal.com/cgi-bin/webscr'
|
||||
|
||||
Make yourself an account on the `PayPal developer site`_ and login. Go to the
|
||||
API Credentials section (you might have to add a test seller account first)
|
||||
and add the API credentials to your settings file::
|
||||
|
||||
PAYPAL_CGI_AUTH = {'USER': 'yourname._1318455663_biz_api1.domain.com',
|
||||
'PASSWORD': '<the password>',
|
||||
'SIGNATURE': '<signature>'}
|
||||
PAYPAL_EMAIL = 'yourname._1318455663_biz@domain.com'
|
||||
PAYPAL_EMBEDDED_AUTH = PAYPAL_CGI_AUTH
|
||||
|
||||
Set ``PAYPAL_APP_ID`` to the registered marketplace app; ask someone in
|
||||
``#amo`` if you don't know it.
|
||||
|
||||
To use PayPal callbacks you'll have to expose your local dev server on a real
|
||||
domain to the Internet. The easiest way to do this is to use
|
||||
http://progrium.com/localtunnel/ Let's say you run your dev server on port
|
||||
8000. You can type this command::
|
||||
|
||||
localtunnel 8000
|
||||
This localtunnel service is brought to you by Twilio.
|
||||
Port 8000 is now publicly accessible from http://4hcs.localtunnel.com ...
|
||||
|
||||
That sets up a proxy to your localhost on http://4hcs.localtunnel.com (or
|
||||
whatever it said). Add that as your ``SITE_URL``::
|
||||
|
||||
SITE_URL = 'http://4hcs.localtunnel.com'
|
||||
|
||||
Most of the sandbox domains require https but they don't have SSL certs! To
|
||||
prepare for this, open up each one in a browser and accept the cert nag so
|
||||
that it doesn't mess up the modal dialog later. For example, load
|
||||
https://sandbox.paypal.com/ in your browser.
|
||||
|
||||
Marketplace payments
|
||||
====================
|
||||
|
||||
Marketplace payments require Solitude
|
||||
http://solitude.readthedocs.org/en/latest/ and WebPay
|
||||
http://webpay.readthedocs.org/en/latest/, two other projects to process
|
||||
payments.
|
||||
|
||||
Both of those projects allow a degree of mocking so that they don't talk to the
|
||||
real payment back-ends.
|
||||
|
||||
You can run solitude on stackato to avoid setting it up yourself, or use the
|
||||
mocked out version at http://mock-solitude.paas.allizom.org/.
|
||||
|
||||
Once you've set up solitude and webpay you will need to configure the
|
||||
marketplace with the host::
|
||||
|
||||
SOLITUDE_HOSTS = ('http://mock-solitude.paas.allizom.org/',)
|
||||
|
||||
You will also want to ensure that the URL ``/mozpay/`` routes to WebPay.
|
||||
|
||||
|
||||
.. _PayPal developer site: https://developer.paypal.com/
|
||||
|
|
@ -1,16 +1,16 @@
|
|||
.. _production:
|
||||
|
||||
=====================
|
||||
Zamboni in Production
|
||||
Olympia in Production
|
||||
=====================
|
||||
|
||||
|
||||
Getting Requirements
|
||||
--------------------
|
||||
|
||||
Grab zamboni from github with ::
|
||||
Grab olympia from github with ::
|
||||
|
||||
git clone git://github.com/mozilla/zamboni.git
|
||||
git clone git://github.com/mozilla/olympia.git
|
||||
git submodule update --init
|
||||
|
||||
You're going to need virtualenv and pip, but I'll let you figure that one out.
|
||||
|
|
@ -43,7 +43,8 @@ https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/
|
|||
|
||||
http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide
|
||||
|
||||
Here's a basic httpd.conf snippet that I used to get zamboni running on my Mac::
|
||||
Here's a basic httpd.conf snippet that I used to get olympia running on my Mac
|
||||
(don't forget to replace ``/Users/jeff`` with what is relevant for your install)::
|
||||
|
||||
# WSGI
|
||||
LoadModule wsgi_module modules/mod_wsgi.so
|
||||
|
|
@ -53,13 +54,13 @@ Here's a basic httpd.conf snippet that I used to get zamboni running on my Mac::
|
|||
|
||||
<VirtualHost *:80> #*
|
||||
ServerName 127.0.0.1
|
||||
WSGIScriptAlias / /Users/jeff/dev/zamboni/wsgi/zamboni.wsgi
|
||||
WSGIScriptAlias / /Users/jeff/dev/olympia/wsgi/olympia.wsgi
|
||||
|
||||
WSGIDaemonProcess zamboni processes=8 threads=1 \
|
||||
python-path=/Users/jeff/.virtualenvs/zamboni/lib/python2.6/site-packages
|
||||
WSGIProcessGroup zamboni
|
||||
WSGIDaemonProcess olympia processes=8 threads=1 \
|
||||
python-path=/Users/jeff/.virtualenvs/olympia/lib/python2.6/site-packages
|
||||
WSGIProcessGroup olympia
|
||||
|
||||
<Directory /Users/jeff/dev/zamboni/wsgi>
|
||||
<Directory /Users/jeff/dev/olympia/wsgi>
|
||||
Order allow,deny
|
||||
Allow from all
|
||||
</Directory>
|
||||
|
|
@ -69,11 +70,11 @@ Here's a basic httpd.conf snippet that I used to get zamboni running on my Mac::
|
|||
``WSGIPythonHome`` points at a pristine virtual environment. That came from
|
||||
http://code.google.com/p/modwsgi/wiki/VirtualEnvironments.
|
||||
|
||||
``WSGIScriptAlias`` points to ``/wsgi/zamboni.wsgi`` in the zamboni checkout.
|
||||
``WSGIScriptAlias`` points to ``/wsgi/olympia.wsgi`` in the olympia checkout.
|
||||
|
||||
``WSGIDaemonProcess`` creates 8 processes and 10 threads. Those numbers are
|
||||
completely arbitrary. I'll update it when we know what works in production.
|
||||
The ``python-path`` argument points to the site-packages directory of our
|
||||
zamboni virtualenv.
|
||||
olympia virtualenv.
|
||||
|
||||
.. note:: This doesn't include media or admin media yet.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ want to create a foreign key to the ``translations`` table, use
|
|||
:class:`django.db.models.ForeignKey` to make it work with our special handling
|
||||
of translation rows.
|
||||
|
||||
A minimal model with translations in zamboni would look like this::
|
||||
A minimal model with translations in olympia would look like this::
|
||||
|
||||
from django.db import models
|
||||
|
||||
|
|
@ -29,55 +29,55 @@ How it works behind the scenes
|
|||
==============================
|
||||
|
||||
As mentioned above, a ``TranslatedField`` is actually a ``ForeignKey`` to the
|
||||
``translations`` table. However, to support multiple languages, we use a
|
||||
special feature of MySQL allowing you to have a ``ForeignKey`` pointing to
|
||||
``translations`` table. However, to support multiple languages, we use a
|
||||
special feature of MySQL allowing you to have a ``ForeignKey`` pointing to
|
||||
multiple rows.
|
||||
|
||||
When querying
|
||||
-------------
|
||||
Our base manager has a ``_with_translations()`` method that is automatically
|
||||
Our base manager has a ``_with_translations()`` method that is automatically
|
||||
called when you instanciate a queryset. It does 2 things:
|
||||
|
||||
- Stick an extra lang=lang in the query to prevent query caching from returning
|
||||
- Stick an extra lang=lang in the query to prevent query caching from returning
|
||||
objects in the wrong language
|
||||
- Call ``translations.transformers.get_trans()`` which does the black magic.
|
||||
|
||||
``get_trans()`` is called, and calls in turn ``translations.transformer.build_query()``
|
||||
and builds a custom SQL query. This query is the heart of the magic. For each
|
||||
``get_trans()`` is called, and calls in turn ``translations.transformer.build_query()``
|
||||
and builds a custom SQL query. This query is the heart of the magic. For each
|
||||
field, it setups a join on the translations table, trying to find a translation
|
||||
in the current language (using ``translation.get_language()``) and then in the
|
||||
language returned by ``get_fallback()`` on the instance (for addons, that's
|
||||
language returned by ``get_fallback()`` on the instance (for addons, that's
|
||||
``default_locale``; if the ``get_fallback()`` method doesn't exist, it will
|
||||
use ``settings.LANGUAGE_CODE``, which should be ``en-US`` in zamboni).
|
||||
use ``settings.LANGUAGE_CODE``, which should be ``en-US`` in olympia).
|
||||
|
||||
Only those 2 languages are considered, and a double join + ``IF`` / ``ELSE`` is
|
||||
done every time, for each field.
|
||||
|
||||
This query is then ran on the slave (``get_trans()`` gets a cursor using
|
||||
``connections[multidb.get_slave()]``) to fetch the translations, and some
|
||||
Translation objects are instanciated from the results and set on the
|
||||
instance(s) of the original query.
|
||||
``connections[multidb.get_slave()]``) to fetch the translations, and some
|
||||
Translation objects are instanciated from the results and set on the
|
||||
instance(s) of the original query.
|
||||
|
||||
To complete the mechanism, ``TranslationDescriptor.__get__`` returns the
|
||||
To complete the mechanism, ``TranslationDescriptor.__get__`` returns the
|
||||
``Translation``, and ``Translations.__unicode__`` returns the translated string
|
||||
as you'd except, making the whole thing transparent.
|
||||
|
||||
When setting
|
||||
------------
|
||||
Everytime you set a translated field to a string value, ``TranslationDescriptor``
|
||||
``__set__`` method is called. It determines what method to call (because you
|
||||
can also assign a dict with multiple translations in multiple languages at the
|
||||
same time). In this case, it calls ``translation_from_string()`` method, still
|
||||
on the "hidden" ``TranslationDescriptor`` instance. The current language is
|
||||
``__set__`` method is called. It determines what method to call (because you
|
||||
can also assign a dict with multiple translations in multiple languages at the
|
||||
same time). In this case, it calls ``translation_from_string()`` method, still
|
||||
on the "hidden" ``TranslationDescriptor`` instance. The current language is
|
||||
passed at this point, using ``translation_utils.get_language()``.
|
||||
|
||||
From there, ``translation_from_string()`` figures out whether it's a new
|
||||
translation of a field we had no translation for, or a new translation of a
|
||||
field we already had but in a new language, or an update to an existing
|
||||
translation.
|
||||
From there, ``translation_from_string()`` figures out whether it's a new
|
||||
translation of a field we had no translation for, or a new translation of a
|
||||
field we already had but in a new language, or an update to an existing
|
||||
translation.
|
||||
|
||||
It instantiates a new ``Translation`` object with the correct values if
|
||||
necessary, or just updates the correct one. It then places that object in a
|
||||
It instantiates a new ``Translation`` object with the correct values if
|
||||
necessary, or just updates the correct one. It then places that object in a
|
||||
queue of Translation instances to be saved later.
|
||||
|
||||
When you eventually call ``obj.save()``, the ``pre_save`` signal is sent. If
|
||||
|
|
@ -87,21 +87,21 @@ important to do this on ``pre_save`` to prevent foreign key constraint errors.
|
|||
|
||||
When deleting
|
||||
-------------
|
||||
Deleting all translations for a field is done using ``delete_translation()``.
|
||||
Deleting all translations for a field is done using ``delete_translation()``.
|
||||
It sets the field to ``NULL`` and then deletes all the attached translations.
|
||||
|
||||
Deleting a *specific* translation (like a translation in spanish, but keeping
|
||||
the english one intact) is implemented but not recommended at the moment.
|
||||
The reason why is twofold:
|
||||
The reason why is twofold:
|
||||
|
||||
1. MySQL doesn't let you delete something that still has a FK pointing to it,
|
||||
even if there are other rows that match the FK. When you call ``delete()``
|
||||
even if there are other rows that match the FK. When you call ``delete()``
|
||||
on a translation, if it was the last translation for that field, we set the
|
||||
FK to ``NULL`` and delete the translation normally. However, if there were
|
||||
any other translations, instead we temporarily disable the constraints to
|
||||
FK to ``NULL`` and delete the translation normally. However, if there were
|
||||
any other translations, instead we temporarily disable the constraints to
|
||||
let you delete just the one you want.
|
||||
2. Remember how fetching works ? If you deleted a translation that is part of
|
||||
the fallback, then when you fetch that object, depending on your locale
|
||||
2. Remember how fetching works ? If you deleted a translation that is part of
|
||||
the fallback, then when you fetch that object, depending on your locale
|
||||
you'll get an empty string for that field, even if there are ``Translation``
|
||||
objects in other languages available !
|
||||
|
||||
|
|
@ -109,8 +109,8 @@ For additional discussion on this topic, see https://bugzilla.mozilla.org/show_b
|
|||
|
||||
Additional tricks
|
||||
-----------------
|
||||
In addition to the above, ``apps/translations/__init__.py`` monkeypatches
|
||||
django to bypass errors thrown because we have a ``ForeignKey`` pointing to
|
||||
In addition to the above, ``apps/translations/__init__.py`` monkeypatches
|
||||
django to bypass errors thrown because we have a ``ForeignKey`` pointing to
|
||||
multiple rows.
|
||||
|
||||
Also, you might be interested into ``translations.query.order_by_translation``.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
# -*- coding: utf-8 -*-
|
||||
# Django settings for zamboni project.
|
||||
# Django settings for olympia project.
|
||||
|
||||
import logging
|
||||
import os
|
||||
|
|
@ -33,11 +33,11 @@ except ImportError:
|
|||
# jingo-minify: Style sheet media attribute default
|
||||
CSS_MEDIA_DEFAULT = 'all'
|
||||
|
||||
# Make filepaths relative to the root of zamboni.
|
||||
# Make filepaths relative to the root of olympia.
|
||||
ROOT = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
|
||||
path = lambda *a: os.path.join(ROOT, *a)
|
||||
|
||||
# We need to track this because hudson can't just call its checkout "zamboni".
|
||||
# We need to track this because hudson can't just call its checkout "olympia".
|
||||
# It puts it in a dir called "workspace". Way to be, hudson.
|
||||
ROOT_PACKAGE = os.path.basename(ROOT)
|
||||
|
||||
|
|
@ -83,7 +83,7 @@ CONN_MAX_AGE = 60
|
|||
|
||||
DATABASES = {
|
||||
'default': {
|
||||
'NAME': 'zamboni',
|
||||
'NAME': 'olympia',
|
||||
'ENGINE': 'django.db.backends.mysql',
|
||||
'HOST': '',
|
||||
'PORT': '',
|
||||
|
|
@ -99,7 +99,7 @@ DATABASES = {
|
|||
# The settings can be copied from DATABASES, but since its not a full Django
|
||||
# database connection, only some values are supported.
|
||||
SERVICES_DATABASE = {
|
||||
'NAME': 'zamboni',
|
||||
'NAME': 'olympia',
|
||||
'USER': '',
|
||||
'PASSWORD': '',
|
||||
'HOST': '',
|
||||
|
|
@ -1049,7 +1049,7 @@ VALIDATION_FAQ_URL = ('https://wiki.mozilla.org/AMO:Editors/EditorGuide/'
|
|||
|
||||
|
||||
## Celery
|
||||
BROKER_URL = 'amqp://zamboni:zamboni@localhost:5672/zamboni'
|
||||
BROKER_URL = 'amqp://olympia:olympia@localhost:5672/olympia'
|
||||
BROKER_CONNECTION_TIMEOUT = 0.1
|
||||
CELERY_RESULT_BACKEND = 'amqp'
|
||||
CELERY_IGNORE_RESULT = True
|
||||
|
|
@ -1169,7 +1169,7 @@ LOGGING = {
|
|||
|
||||
|
||||
HEKA_CONF = {
|
||||
'logger': 'zamboni',
|
||||
'logger': 'olympia',
|
||||
'plugins': {
|
||||
'cef': ('heka_cef.cef_plugin:config_plugin', {
|
||||
'syslog_facility': 'LOCAL4',
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче