4 ms·

Uh, what? Topic Vagrant-Related? ------------------------------------------------------------ Vagrant

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 15y ago
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.
- dolinsky 15y ago
  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 15y ago
    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 15y ago
      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 15y ago
    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.
- moe 15y ago
  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.
- stevelosh 15y ago
  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 15y ago
    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.

niels 15y ago

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.

dolinsky 15y ago
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 15y ago
  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 15y ago
    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 15y ago
  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.
moe 15y ago
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.
stevelosh 15y ago
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 15y ago
  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.