Moving a Django project to another directory/server

[Rex]

I'd like to use a revision control system to keep up to 3 versions of
my Django project:

- A production version, which will be running on a remote Linux server
- A test version, which will be running on the same remote server for
my colleagues to test out before I make it public
- (Possibly) a local development version on my machine.

So far I have been planning to use Bazaar for version control.

I am wondering the following:
- How can I simultaneously run two versions of the same project on the
same machine? I am primarily concerned about PYTHONPATH conflicts,
since both projects would have the same name (unless there's an easy
workaround).
- Is copying a Django project to another machine/directory simply a
matter of transferring the project's directory to the desired
location, or does some other work have to be done first too?

Thanks,
Rex

[Fergus]

On 14 Mar, 21:42, Rex <rex.eastbou...@gmail.com> wrote:
> I'd like to use a revision control system to keep up to 3 versions of
> my Django project:

...

> So far I have been planning to use Bazaar for version control.

Good choice.

> - How can I simultaneously run two versions of the same project on the
> same machine? I am primarily concerned about PYTHONPATH conflicts,
> since both projects would have the same name (unless there's an easy
> workaround).

I do it by:
- running several virtual hosts in apache
<http://httpd.apache.org/docs/2.0/vhosts/>
- they have different server names. e.g. www.mydomain.com and
staging.mydomain.com, test.mydomain.com
- and each runs the project's code from a different folder - in Bazaar
this is easy to arrange by using checkouts of various branches of your
code
<http://bazaar-vcs.org/CheckoutTutorial>

As far as I am aware [assuming you're using modpython with Apache] in
each virtual host when you tell apache:

<location "/mysite/">
...
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonPath "['/path/to/project'] + sys.path"
...
</location>

... that only adds your project to the pythonpath for that virtual
host when it runs the code in /path/to/project. So it wouldn't also be
in the pythonpath of another virtual host, or available at the command
line.

As long as the same module name isn't already on PythonPath, there
should be no problems or mysterious errors due to this.

> - Is copying a Django project to another machine/directory simply a
> matter of transferring the project's directory to the desired
> location, or does some other work have to be done first too?

Django projects, unless you do some dark magic, are simply a set of
files.

Assuming you know how Bazaar keeps track of files and changes
<http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html>
you'd only need to worry about:
- the database supporting the application
- and your settings.py file

Presumably your settings file will want to be different for the
various versions and sites of your project so version controlling that
file and updating it at each site will become a chore you won't like,
and you'll possibly forget to turn DEBUG = False on the production
site.

What I do is:
- create settings.py with all settings that won't change over all
sites, and sensible defaults for all the ones that will
- at each site, put all site-specific settings in local_settings.py
[to sit alongside settings.py], where you can override the values from
settings.py
- at the end of settings.py, tell settings.py to import local_settings
- then tell Bazaar to ignore the local_settings.py file in that
repository [bzr ignore local_settings.py]: as people will probably
make changes and commit them at several locations, you don't want
their local settings to spill into your repository

Hope that helps.

Ferg

[Carlos A. Carnero Delgado]

Hello,

what follows is NOT a solution to your needs, but I wanted to chime
in with a workflow that has proved effective to my three-developers
team. We have two "environments": developer and production. Each
developer has, in their respective home directory (be that Windows or
Linux,) a file called .project-name.properties (yes, hidden in Linux.)
There we have the specifics for each developer environment (database,
mail server, etc.)

This file is a text file formatted in such a way that can be read by
Python's own ConfigParser. Now, being that settings.py is plain
Python, what we do is, at the very top of that file (pseudo-code)

if can read and parse (user's home directory + "..project-name.properties):
# we're dealing with the developer environment so set the settings
# to what we parse from the file
else:
# we're dealing with the production environment so the settings are
# "fixed" to that of the production server

The advantage for us is that allows each developer to dynamically
configure the project to their own environment and at the same time we
have the production settings fixed in the source code. And all of this
neatly under revision control! Should the need arise for other
production settings we will branch.

So far this setup has worked well, although we're dealing with
smallish projects and teams. Don't know if this helps but I'd find
this thread interesting of others could provide their experiences.

HTH,
Carlos.