It's a little bit odd, that the first tip is using Vagrant, and almost all the o...

stevelosh · on June 30, 2011

Uh, what?

    Topic                                       Vagrant-Related?
    ------------------------------------------------------------
    Vagrant                                     Y
        Why Vagrant?                            Y
        Using Fabric to Stay Fast and...        Y
    Wrangling Databases with South              N
        Useful Fabric Tasks                     Y
    Watching for Changes                        N
        Using the Werkzeug Debugger with...     N
        Pulling Uploads                         N
        Preventing Accidents                    N
    Working with Third-Party Apps               N
        Installing Apps from Repositories       N
        Mirroring Repositories                  N
        Using BCVI to Edit Files                Y
    Improving the Admin Interface               N
        Enter Grappelli                         N
        An Ugly Hack to Show Usable Foreign...  N
    Using Django-Annoying                       N
        The render_to Decorator                 N
        The ajax_request Decorator              N
    Templating Tricks                           N
        Null Checks and Fallbacks               N
        Manipulating Query Strings              N
        Satisfying Your Designer with Typogrify N
    The Flat Page Trainwreck                    N
    Editing with Vim                            N
        Vim for Django                          N
        Filetype Mappings                       N
        Python Sanity Checking                  N
        Javascript Sanity Checking and Folding  N
        Django Autocommands                     N
    Conclusion                                  N

5/32 sections are Vagrant-related. 5/32 != almost all.

EDIT: My bad, there are only 31 sections total. Still, 5/31 is not almost all.

niels · on June 30, 2011

You are right. My bad. My point though, was that I think the cost in terms of complexity of using Vagrant for development is too high. The goal of having your dev environment match your prod. env. is not the right approach in my opinion. This the role of the staging environment.

moe · on June 30, 2011

The goal of having your dev environment match your prod. env. is not the right approach in my opinion.

Indeed. It's not just the right approach, it's the only approach for non-trivial applications.

Sorry for being a bit snarky, but I've seen the alternatives crumble under stress way too often.

dolinsky · on June 30, 2011

The goal should be to keep environments as similar as possible, which vagrant helps to accomplish. Just because you can develop locally on your Mac before pushing to a QA/Dev/staging environment doesn't mean you should.

Obviously your Dev environment isn't going to be able to match every aspect of your production environment, but keeping the same platform builds across environments is something that all teams should be aiming for.

niels · on June 30, 2011

That might be your goals. My dev environment should be as painless and fast as possible. This is what I spend all day using.

dolinsky · on June 30, 2011

It's what I spend all day using as well. The dev environments I've either implemented or been a part of (web centric envs) have all used local folders mounted to VMs that provide that painless and fast requirement you speak of while removing any pain points associated with varying platforms. You dont need to sacrifice the former to achieve the latter.

erwinelling · on July 1, 2011

And wat hasn't been touched upon here, but what's maybe even more important - at least for my team - : The same platform builds at everyone in the team.

stevelosh · on June 30, 2011

Doesn't this just move the pain of environment mismatch from dev->prod to dev->staging?

If you use something OS-specific on your dev machine you'll need to fix it at SOME point, right?

niels · on June 30, 2011

Yes, it does. I just think imposing prod. setup testing on your dev env., is the wrong place to do it. For many django apps, I've been able to use testserver, staticserve, dummycaching, synchrounous Celery tasks, etc for development. Just configs that works on checkout. If I need a special database, or something with a non standard interface I add only that to my setup.