24 |
24 |
.. code-block:: console
|
25 |
25 |
|
26 |
26 |
$ virtualenv ~/synnefo-env
|
27 |
|
$ . ~/synnefo-env/bin/activate
|
|
27 |
$ source ~/synnefo-env/bin/activate
|
28 |
28 |
(synnefo-env)$
|
29 |
|
|
30 |
|
Any :command:`pip` commands executed from now on, affect the ``synnefo-env``
|
31 |
|
virtualenv.
|
|
29 |
|
|
30 |
Virtualenv creates an isolated python environment to the path you pass as the
|
|
31 |
first argument of the command. That means that all packages you install using
|
|
32 |
:command:`pip` or :command:`easy_install` will be placed in
|
|
33 |
``ENV/lib/pythonX.X/site-packages`` and their console scripts in ``ENV/bin/``.
|
|
34 |
|
|
35 |
This allows you to develop against multiple versions of packages that your
|
|
36 |
software depends on without messing with system python packages that may be
|
|
37 |
needed in specific versions for other software you have installed on your
|
|
38 |
system.
|
32 |
39 |
|
33 |
40 |
* It is also recommended to install development helpers:
|
34 |
41 |
|
35 |
42 |
.. code-block:: console
|
36 |
43 |
|
37 |
|
(synnefo-env)$ pip install django_extensions
|
|
44 |
(synnefo-env)$ pip install django_extensions fabric>=1.3
|
38 |
45 |
|
39 |
46 |
* Create a custom settings directory for :ref:`snf-common <snf-common>` and set
|
40 |
47 |
the ``SYNNEFO_SETTINGS_DIR`` environment variable to use development-specific
|
... | ... | |
91 |
98 |
.. code-block:: console
|
92 |
99 |
|
93 |
100 |
(synnefo-env)$ git clone https://code.grnet.gr/git/synnefo synnefo
|
|
101 |
(synnefo-env)$ git clone https://code.grnet.gr/git/pithos pithos
|
94 |
102 |
|
95 |
103 |
* Install the software components you wish to work on inside the
|
96 |
104 |
virtualenv, in development mode:
|
... | ... | |
117 |
125 |
|
118 |
126 |
(synnefo-env)$ snf-manage runserver
|
119 |
127 |
|
120 |
|
or, if you have the django_extensions and werkzeug packages installed:
|
|
128 |
or, if you have the ``django_extensions`` and ``werkzeug`` packages installed:
|
121 |
129 |
|
122 |
130 |
.. code-block:: console
|
123 |
131 |
|
... | ... | |
149 |
157 |
|
150 |
158 |
.. code-block:: console
|
151 |
159 |
|
152 |
|
$ snf-manage syncdb # Create / update the database with the south tables
|
153 |
|
$ snf-manage migrate # Perform migration in the database
|
|
160 |
$ snf-manage syncdb --all # Create / update the database with the south tables
|
|
161 |
$ snf-manage migrate --fake # Perform migration in the database
|
|
162 |
|
|
163 |
|
|
164 |
Note that ``--all`` and ``--fake`` arguments are only needed when you are
|
|
165 |
initializing your database. If you want to migrate a previously create databse
|
|
166 |
to the latest db scheme just run the same commands without those arguments.
|
154 |
167 |
|
155 |
|
Note that syncdb will create the latest models that exist in the db app, so some
|
156 |
|
migrations may fail. If you are sure a migration has already taken place you
|
157 |
|
must use the ``--fake`` option, to apply it.
|
|
168 |
If you are trying to migrate a database that already contains the changes that
|
|
169 |
applied from a specific migration script, ``south`` will probably notify you for
|
|
170 |
inconsistent db scheme, a workaround for that issue is to use ``--fake`` option
|
|
171 |
for a specific migration.
|
158 |
172 |
|
159 |
173 |
For example:
|
160 |
174 |
|