How I develop Django projects | Hacker News Reader

How I develop Django projects

blog.kristian.io

64 pointsoellegaard48 comments

I use Vim for most work and have used Sublime a fare bit as well. The 75% sale that Jetbrains had lured me into picking up a PyCharm license, but only reluctantly. I was immediately put off by the perceived heaviness and general ugliness of the whole thing compared to what I was used to.

But... after getting over that and putting some time into learning the program, I can highly recommend it for Django development. It is incredibly feature rich with a lot of Django-smart tools. Though I still love and use Vim, one instance of runtime debugging inside a problematic template using PyCharm made it a permanent tool for when I'm doing Django (and other Python) work.

We use Fabric instead of Makefiles - Fabric is much more powerful and fabfiles are written in Python.

Make commands can also be written in Python...

I'm not saying using Fabric is a bad idea, just that about all it shares with Make is being a vaguely useful place to namespace a bunch of commands.

> Furthermore, you don’t have to write `workon <project>` but just `work` if you are in the correct directory

ohmyzsh has a virtualenvwrapper plugin that does it automatically when you cd into the directory of the same name as the virtualenv.

btw I don't get why you alias mkvirtualenv for venv, workon for work, don't you use tab autocompletion?

The reason why I don't use virtualenvwrapper is mainly to have the virtualenv within the project, e.g. in case I want to get rid of it. I always only have the virtualenvs that I use around.

frankly I don't understand the benefits of that, but whatever suits you.

btw aliases are not zsh specific. basically, the only thing that you mention that is specific to zsh there is the ohmyzsh theme :)

True, Maybe I should add more information about ohmyzsh - specifically all the plugins.

Things I would suggest differently are to use a settings directory and have a settings/base.py then a settings/development.py settings/local.py settings/production.py, and check all of these into git. Then put an environment variable export DJANGO_SETTINGS_MODULE=yourapp.settings.local into your postactivate script.

There was a Django best practises book that has this stuff in it.

Also use Fabric instead of make, and have a separate project (installable as a Python module) that has your "common" Fabric commands for deployment stuff.

If you are on Linux, never ever ever do "sudo pip". Use your package manager for system packages.

Actually I prefer to have only one settings file and configure everything else with environment variables. For me this is more clean.

Make is generally installed on most systems, therfore I prefer it over fabric - but the idea is the same.

I disagree about sudo pip on Linux, e.g. python-virtualenv wasn't updated for a long time in Ubuntu. Therefore, I still recommend getting the newest with pip. You coud apt-get python-pip, but most other things I would get from pip.

"Actually I prefer to have only one settings file and configure everything else with environment variables. For me this is more clean."

Heavily seconded. After many years of having separate files, this grew very unwieldy with multiple environments, machines, developers, etc. The env-variable route is much better, much easier to configure separately for different machines, etc.

Also, this is the way Heroku does it - you load up a new server and run several "set env variable to {X}" commands to configure it. I think this is based on the 12-factor app system. (http://www.12factor.net/)

config layers are one of the best things ever. You can have settings/production.py set up without sensitive information for traceability and then the ops team can apply another config file with uids/passwords/red keys/etc.

One thing that I think would be helpful in posts like these would be database configuration with Postgres. While Heroku has made it incredibly simple on OSX[0], figuring everything out on Ubuntu was a nightmare in comparison.

Also, fun story: I've been working on both my MacBook and my Chromebook, and I've been deploying to Heroku. This resulted in me accidentally ending up with three versions of my settings.py. Always a pleasant sensation to runserver only to end up staring at a database error. Not at all terrifying.

[0]: http://postgresapp.com/

You are right. I forgot to mention Postgres.app! I use that all the time. Thanks! ;)

Out of curiosity, how do you develop on the Chromebook?

I used a script called crouton[0] developed by a Googler to install an Ubuntu chroot. I get to use Chrome OS as my browser (and it's a very good browser) and I get a fully powered Linux instance to develop with locally in crosh (and it's a very good-looking shell). I use vim, but if you want a GUI, it's very easy to install your DE of choice, since it's the same as it would be as any other Ubuntu machine.

I haven't run into any problems using it this way that many other people seem to have. Judging from online forums, many people install a chroot, Unity, and then everything falls apart for them because Dropbox/Sublime Text/something isn't ARM compatible. Sticking with just a browser and a CLI has made development on the Chromebook simple.

[0]: https://github.com/dnschneid/crouton

Would anyone be interested in a mailing list / group for bay area django developers? I feel like there are a bunch of us but we are all scattered!

Yes.

There's the SF Django meetup, which has meetings in both SF and Oakland: http://www.meetup.com/The-San-Francisco-Django-Meetup-Group/...

Thank you for this. Personally I use Sublime and it does a lot of the things the article mentions, but I will take a look at PyCharm.

We use vagrant and salt stack to maintain a consistent development environment across developers as well as our production environment. It works very well, and gets new developers going in no time. I'll write a blog post about this on the Opbeat blog sometime.

I use Sublime all the time, as well, but mostly for small projects. For instance, on one of my current projects we have a 600+ line models.py - then you really start to appreciate the CMD+click jump to definition ;)

I will be looking forward to your blog post. Considered Salt as well, but didn't get a chance to take a proper look yet. We use puppet for now, also with Vagrant.

I believe the SublimeCodeIntel plugin will give you the alt+click functionality. It says so in the documentation at least: https://github.com/Kronuz/SublimeCodeIntel - I haven't tried it though.

Sublime Text 3 has jump to definition built in.

Just wanted to throw in some love for Komodo Edit. It's 100% free and awesome. It doesn't force you into the whole "save a project before you can do anything" paradigm (though to be fair, I have no idea if PyCharm does this either), and it just feels more complete than Sublime for a full IDE.

Komodo is pretty awesome, but I though I'd chime in with the perspective of someone who switched from Komodo Edit to PyCharm last month. I've been using Komodo Edit for nearly a year, and was quite happy with it as a Python editor. (Our build and test utils are all in makefiles and other scripts, so I run them on the command line.) It's an all-around awesome editor.

I switched to PyCharm a month ago and am EXTREMELY happy with it. I have not touched Komodo since then. The ONLY things I miss from Komodo are syntax highlighting of $Everything (e.g. Makefiles, Bash scripts, Perl, etc) and the ability to easily open files from elsewhere (e.g. /tmp/foo.bar). Both are things that Jetbrains have said detracts from their focus of delivering an awesome __Python__ IDE -- and I grudgingly agree. PyCharm is more polished than I'd dreamed - so much so that this is the first time I've been willing to spend money on an editor in over a decade.

If you already have an existing project folder, you don't need to create a new Workspace or Project -- just open that folder.

For what it's worth, I picked up PyCharm on a whim during JetBrains' doomsday sale in December. I haven't done any serious Django development yet (still learning), but as an IDE I thoroughly enjoy it. As a daytime Java developer I'm seriously considering picking up their Java IDE because of the quality.

Just to reiterate, this is coming from someone new to Django, not a power user.

Another good post: http://www.jeffknupp.com/blog/2012/10/24/starting-a-django-1...

That one covers virtualenvwrapper, too, on top of virtualenv, so you don't have to deal with that cruft in your project directory at all.

for a more indepth discussion of django best practices, check out the excellent https://django.2scoops.org/ ...though I don't share their proclivity for CBV's

After reading two scoops I started a new Django project and my first one using CBVs and I couldn't be happier. It now seems like django has two modes classical everything manual (FBVs) and the new some magic included mode (CBVs). You just have to choose.

   You run `virtualenv .` in your project folder and it will
   setup a virtual environment. To enter the virtual         
   environment run `source bin/activate`. I don’t know about
   you, but I hate to see bin/ lib/ and other folders in my
   project directory, so I made a wrapper around virtualenv
   in my ZSH scripts.

Why not just make the virtualenv elsewhere (I use ~/virtualenvs/)?

Also, how about django-extensions? I don't know what I'd do without runserver_plus and shell_plus.

Simply because I like the project and virtualenvs to be attached. I used to work with many different customer sites and I would delete them once I did not have to work on them anymore. In this way, I would also automatically remove the virtualenvs from these projects.

I use emacs running in terminator, or WingIde as my preferred editors. I tried out PyCharm but it gathers dust. IntelliJ tried, but could not eliminate the Java smell completely.

I wonder why pythonbrew gets no love - http://stacktoheap.com/blog/2013/03/11/why-use-virtualenv-wh...

For me, pythonbrew + autoenv ( https://github.com/kennethreitz/autoenv ) is must for development.

What pain points does pythonbrew solve? Im curious as the linked blog post was a bit light on detail

It helps in managing pythons AND is a wrapper to virtualenv for managing environments. And it solves some pain points that virtualenvwrapper solves, like virtual environments files external to project etc.

If you are from ruby / rails world, you will love and be at home with pythonbrew.

I used pythonbrew for a while, but as I moved into testing apps with multiple versions of python (via tox), using pythonbrew's executables became more trouble than it was worth.

Because of that, I've gone back to using homebrew to compile multiple versions of python and letting tox utilize those. Homebrew takes care of pip & distribute so adding virtualenv & virtualenvwrapper is a simple oneliner after the fact.

Autoenv is pretty pointless because you can assign a "project dir" to a virtualenv (and also postactivate scripts).

So I can just do workon myproject and be instantly transported to the right place with the right environment.

Is that versioned so that all you teammates do the same thing?

It is much cleaner to use OS packages for the different versions of Python you need. There is no problem asking virtualenv to use a specific installed version.

Please add how you manage and install dependencies (including stuff from github that is not on pypi)

Great idea, thanks!

Small typo: 'sudp pip install virtualenv'

I think you meant 'sudo'

As for file structure, I thought Django came with a pre-built structure? I may be wrong, as I've only used Django for quick side projects and not really any extensive development.

Great post nonetheless!

Thank you very much, I'll fix that right away! ;)

Django comes with a structure, only slightly different.

django-admin.py/manage.py[0] can enforce a typical structure using startproject/startapp. It's actually very similar to the OP's, except the project has an app of the same name that contains settings.py, wsgi, etc. It looks like the OP puts apps inside the folder that would usually be a standalone app.

I'm sure there's a page on djangoproject.com somewhere that talks about this but I can't find it right now.

[0]: https://docs.djangoproject.com/en/1.5/ref/django-admin/

Django 1.4 introduced custom templates for projects and applications. Useful for when you've settled on a file structure: https://docs.djangoproject.com/en/dev/ref/django-admin/#djan...

Great article.

Also for me, it was a timely recommendation of a branch of gitx - I just started using gitx yesterday, and this branch of it seems like it will be of great benefit.

Does anyone know other tools that make life easer for git users on OSX?

I like SourceTree for my gui git needs on OSX.

Wow.

This is amazing. I only barely played around with it, but it's already answered a lot of my known (and unknown) desires - easy to see the whole tree (like gitx), easy to see what changes exist between any two revisions, easy to see what changes remain uncommited, easy to cherry-pick specific changes...

Seriously, this is an awesome tool.

And you can't beat the price, free.

Integrates well with github and bitbucket. It's what I recommend to designers to use for git.

Reply on news.ycombinator.com