

Starting a Django Project the Right Way - Brajeshwar
http://www.jeffknupp.com/blog/2012/02/09/starting-a-django-project-the-right-way/

======
lloeki

        $ git add .
    

Wait, what? No!

This will add the whole venv, which contains symlinks, scripts with shebangs,
and potential binaries, and as such is totally linked to your system, so this
definitely breaks if your python ends up in another location or you're
entirely on another OS.

What should be done is

    
    
        virtualenv env --no-site-packages
        echo "/env" >> .gitignore
        pip freeze > requirements.txt
    

So when you want to restore/deploy you'd do

    
    
        git clone foo
        cd foo
        virtualenv env --no-site-packages
        source ./env/bin/activate
        pip install -r requirements.txt
    

I'm not even considering the issues regarding the presented git workflow. If
one wants to semi-automate a git workflow, one would rather use git-flow
instead of this prepare_deployment hack.

~~~
tocomment
So do you use virtualenv in production? Is there a good tutorial on this for
my developers?

~~~
tocomment
What's the benefit of using virtualenv in production? And actually what's the
benefit in general?

~~~
adolph
_The basic problem being addressed is one of dependencies and versions, and
indirectly permissions. Imagine you have an application that needs version 1
of LibFoo, but another application requires version 2. How can you use both
these applications? If you install everything into /usr/lib/python2.7/site-
packages (or whatever your platform’s standard location is), it’s easy to end
up in a situation where you unintentionally upgrade an application that
shouldn’t be upgraded._

From: <http://www.virtualenv.org/en/latest/index.html>

~~~
AUmrysh
Additionally, you may run into a problem where your distribution only offers
certain versions of python and its packages, when you need newer versions. On
systems like CentOS, this becomes a bit more complex as you can wind up in
'dependency hell' trying to compile everything you may need for a complex
python program. virtualenv and pip make this very easy to manage and set up.

------
scott_w
We find using --system-site-packages on your deployment is a better solution
for deploying Django - especially when it comes to dependencies that need to
be compiled.

It gives you flexibility on your environment and lets you deploy onto machines
without a C compiler, or strange setup requirements e.g. psycopg2 on OS X, and
PIL on Ubuntu.

You then install Django, and other Python-only dependencies inside your
virtualenv, which stops you polluting the global Python path.

It requires some discipline in your development setup, but it means you're
able to develop across whatever platform you choose, and simplifies
deployment.

~~~
dominicrodger
What's wrong with PIL on Ubuntu? If you're running into needing to repoint
JPEG_ROOT/ZLIB_ROOT - I've started avoiding that by symlinking where PIL
expects things to be to where they actually are). Works a charm, and avoids
using --system-site-packages.

~~~
scott_w
I used to do this, but it feels like a suboptimal solution. I could use Fabric
to ensure the links are there but it adds more complexity to the setup:

a) Another step to remember b) Requires a compiler on the production system c)
Requires you to manually resolve the image library dependencies

Multiplying that across multiple packages can quicky become a headache. It's
much easier to let the OS package manager deal with this, and will make your
system more robust over time.

------
yummyfajitas
Don't use Fabric. Seriously, just don't.

It's easier to set up than puppet/chef, but you lose a huge amount of
flexibility/robustness. All fabric does is runs commands on host machines.
Dependency management is your responsibility.

~~~
arocks
Interestingly most posts which recommend using Puppet/Chef depend on Fabric
for deployment. Is a mutually exclusive or pure Puppet/Chef approach better in
any way?

~~~
yummyfajitas
If you want to use fabric (or a shell script) to run puppet, go ahead. I'm
just suggesting that you _really_ want to use a deploy system with proper
dependency management.

The issue I ran into with fabric is that I often got stuck in dependency hell.
The following is fabric's simplest method of dependency management:

    
    
        def install_foo():
            install_foo_dependency()
            ...
    

Unfortunately, you don't want to do this every time you deploy because
install_foo_dependency() might take a while to run. You can work around it by
checking inside install_foo_dependency whether it's already there. In
practice, you probably won't always do this. Puppet usually has recipes which
already do this for you.

So you typically have functions like:

    
    
        def full_deploy():
            install_foo_dependency()
            install_foo_without_dependency()
    

In theory, you can do things right with fabric. In practice, you have to do a
lot of work to replicate what puppet (together with assorted easy to find
recipes) gives you out of the box.

~~~
irahul
> I'm just suggesting that you really want to use a deploy system with proper
> dependency management.

Why not use pip(pip install -r reqs.txt)?

    
    
        def install_deps():
            local('pip install -r reqs.txt')
    

Or if you are talking system dependencies, use apt-get or yum or whatever
comes with your system from within fabric.

~~~
yummyfajitas
Often installing a dependency involves more code:

    
    
        with in_tmp_dir():
            run('wget http://someserver/project_bleeding_edge.tar.gz')
            run('tar -xvzf project_bleeding_edge.tar.gz')
            run('./configure; make;')
            sudo('make install')
            put('conf/server.conf', 'server.conf')
            sudo('mv server.conf /etc/server.conf')
    

(I forget if in_tmp_dir is builtin, but if not it does exactly what it sounds
like.)

------
5h
I did only scan the article, but using having a remote repo hosting service
(is it really developing _on the server_ while using git?!) configured,
branches for feature-dev/bugs/staging/qa/production, vm configuration via
chef/puppet, separated settings files, fault reporting etc etc are most (for
me) all a part of doing it the "right way" before writing a single line of my
own code.

~~~
Terretta
Sounds like you have a great blog article just begging to be let out.

~~~
5h
Heh, at some point soon[1]... once i've migrated the rest of my websites into
rackspace cloud & their "next generation" offering stabilises i'll be writing
a "This is how we do it now, it might work for you" type article.

[1] for a yet to be determined value of soon

------
zalew
> If you do a lot of Django development, just dump all of the commands above
> into a fabfile and make creating a proper Django app a one step process.

if you do a lot of django development, you probably already got a kick ass
project template with a requirements file, so you have a basic working website
with all the commonly used modules set up and running in 5 seconds.

------
tbatterii
I think buildout addresses the deployment problem better than virtualenv +
fabric. Only "problem" is it's zope heritage and thus not cool enough for
bloggers to use.

------
sergiotapia
I really dislike this trend Rails has brought that a Model maps directly to a
database table.

I've coded in CakePHP, Rails and ASP.Net MVC3, and out of all three MVC3 was
the cleanest one for me just because any Model you created was just a simple
POCO class. It didn't map anywhere and prevented you from shooting yourself in
the proverbial foot. Problems inherent in Rails and CakePHP if you aren't
careful.

I even asked a question on SO about this issue, ZERO responses if you can
believe that. I guess the silence is answer enough. ;)

[http://stackoverflow.com/questions/11424719/where-do-
viewmod...](http://stackoverflow.com/questions/11424719/where-do-viewmodels-
fit-in-with-ruby-on-rails-and-activerecord)

~~~
danso
I read your SO post but wasn't quite sure what you were trying to get at,
because I wasn't quite sure how you perceive the MVC structure in Rails to be.

~~~
jspiral
I read it as a statement that he doesn't like the Active Record pattern

------
DanielN
I would highly recommend using <http://code.google.com/p/django-evolution/>
over South

~~~
jimray
Any particular reason why? South appears to be under much more active
development.

~~~
DanielN
To be honest I haven't used South in about a year so I don't really know how
it has changed. But with South I always seemed to be running into issues of it
allowing you to modify existing elements of your schema but not add new
elements or modify types in your schema.

~~~
GeneralMaximus
I started using South about two months ago for both my personal website
(<http://ankursethi.in>) and a large-ish CRUD app that I'm working on. In both
cases, South has been able to add to and modify the types in my schema. You
should give it a whirl again.

