5 ms·

Don't know if I understand. You have the one develop box with all the languages/server/databases on there. Then when you decide to start a PHP project, you keep

by bti 13y ago

Don't know if I understand. You have the one develop box with all the languages/server/databases on there. Then when you decide to start a PHP project, you keep a copy of that box in with the project files? Doesn't this result in multiple boxes sitting around? Or does the Vagrantfile specify the environment and when you vagrant init develop it recreates it? I've never used Vagrant but am interested in starting to do something like this.

taylorlapeyre 13y ago
The Vagrantfile specifies the enviroment, and vagrant init develop creates a new Vagrantfile with the base vm specified as "develop". There's only one box, and you add it to vagrant with "vagrant box add develop path/to/develop.box". After that, you can delete the develop.box file from your computer: it now exists somewhere in the nethers of vagrant's configuration.
- bti 13y ago
  So as you find new tools you want to use, do you just update your develop box? Do you have an example of a Vagrantfile you used for a project? I guess the main thing I can't get is say I have custom nginx settings or MySQL settings I need in a project. Do I setup those through Chef? Thanks for the article, lots to look into.
  - taylorlapeyre 13y ago
    It depends. If I begin using something new (say, Go) and end up using it a lot then I will install it on develop and repackage it into the "develop" box again. This takes about 5 minutes. If it's something specific for a project (i.e., a jekyll website), I just write a quick shell script to install jekyll in the Vagrantfile for that project instead of repackaging the whole box. As for your second question, yes, you would have a specific Vagrantfile/box for a project where you need a specific enviroment. My "develop" box is a general case. Here's a (slightly modified) example of a Vagrantfile that I use with a project: https://gist.github.com/taylorlapeyre/5399974 https://gist.github.com/taylorlapeyre/5399974
tomku 13y ago
The Vagrantfile specifies the environment as a combination of a base box, VM settings and optionally a provisioning script/recipe/whatever to run. The base box is only stored once, and individual VMs for projects are created from that box and destroyed when you don't need them any more. It's common to use something like Chef or Puppet to provision the software that you actually need for each project rather than just put everything in the base box, but the author chose to just make an all-inclusive box instead.
tunesmith 13y ago
I'm still a bit confused - what if you are simultaneously working on two projects that each require a different version of Ruby? Do you have two different vagrant boxes lying around?
- chewxy 13y ago
  You start off with the same baseVM (I used to use Precise32, switched to Precise64 for the first time yesterday). You specify the boxes which is based off your base VM. From there, the path of evolution for each box will take place individually. If you have a Vagrantfile that specify for one project to use Ruby2.0beta and another Vagrantfile for another project to use Ruby1.9, you essentially have two boxes, two execution environments, but you still code on the same machine.
- taylorlapeyre 13y ago
  User chewxy explained it well, but even more simply I just have two different versions of Ruby on my development box. 1.9.3 and 2.0.0.
- awongh 13y ago
  if nothing else is different, then you can still use rvm inside the VM. If they are different environments (one is a colo rack and one is an AWS instance) then you would want 2 vagrant boxes to more closely duplicate each environment.
chewxy 13y ago
Vagrant is the execution environment that you set up, share and whatnots. Your dev environment (IDE, text editor, etc) can still be in the original environment you are familiar with. For example, just yesterday, a colleague wanted access to Fork the Cookbook's source (he was supposed to be helping out on frontend javascript). But because some bits of the code is written to be Linux specific, he needed a Linux box while working on a non-Linux box. So I spent 30 mins creating a Vagrantfile, specifying the environment which Fork the Cookbook runs in. He takes it, runs the env, provisions with the existing provisioning script, and tadah, you get an environment where you get to run the code in. Due to the synced directories, you can code in whatever env you are hosting on: it's like dropbox between your computer and the virtual box. Network pass throughs allow your host (i.e your physical machine) to use networks defined virtually in your virtual computer. Great for sharing execution env and getting other people started. Not really necessary if you're working alone IMO
- bosie 13y ago
  > Vagrant is the execution environment that you set up, share and whatnots. Your dev environment (IDE, text editor, etc) can still be in the original environment you are familiar with. Sorry if i have missed this but how do you execute/debug in the IDE through Vagrant? e.g. how would rubymine use vagrant's ruby binary?
  - lojack 13y ago
    In the case of any debugging in your IDE, you'd want to use remote debugging (which, I believe, rubymine supports). Otherwise, I'd connect to the virtual machine via ssh and debug there.
  - chewxy 13y ago
    I'm not sure about Rubymine since I'm more of a Python/Golang guy (also I use SublimeText). In Python, there is an IDE called PyCharm that has a remote intepreter function. I expect all good IDEs to have something like that too: remote intepreter/libraries/etc EDIT: A quick Google yielded this: http://www.jetbrains.com/ruby/webhelp/configuring-remote-interpreters-via-virtual-boxes.html http://www.jetbrains.com/ruby/webhelp/configuring-remote-int...

by bti 13y ago

taylorlapeyre 13y ago

The Vagrantfile specifies the enviroment, and vagrant init develop creates a new Vagrantfile with the base vm specified as "develop". There's only one box, and you add it to vagrant with "vagrant box add develop path/to/develop.box". After that, you can delete the develop.box file from your computer: it now exists somewhere in the nethers of vagrant's configuration.

bti 13y ago
So as you find new tools you want to use, do you just update your develop box? Do you have an example of a Vagrantfile you used for a project? I guess the main thing I can't get is say I have custom nginx settings or MySQL settings I need in a project. Do I setup those through Chef? Thanks for the article, lots to look into.
- taylorlapeyre 13y ago
  It depends. If I begin using something new (say, Go) and end up using it a lot then I will install it on develop and repackage it into the "develop" box again. This takes about 5 minutes. If it's something specific for a project (i.e., a jekyll website), I just write a quick shell script to install jekyll in the Vagrantfile for that project instead of repackaging the whole box. As for your second question, yes, you would have a specific Vagrantfile/box for a project where you need a specific enviroment. My "develop" box is a general case. Here's a (slightly modified) example of a Vagrantfile that I use with a project: https://gist.github.com/taylorlapeyre/5399974 https://gist.github.com/taylorlapeyre/5399974

tomku 13y ago

The Vagrantfile specifies the environment as a combination of a base box, VM settings and optionally a provisioning script/recipe/whatever to run. The base box is only stored once, and individual VMs for projects are created from that box and destroyed when you don't need them any more. It's common to use something like Chef or Puppet to provision the software that you actually need for each project rather than just put everything in the base box, but the author chose to just make an all-inclusive box instead.

tunesmith 13y ago

I'm still a bit confused - what if you are simultaneously working on two projects that each require a different version of Ruby? Do you have two different vagrant boxes lying around?

chewxy 13y ago
You start off with the same baseVM (I used to use Precise32, switched to Precise64 for the first time yesterday). You specify the boxes which is based off your base VM. From there, the path of evolution for each box will take place individually. If you have a Vagrantfile that specify for one project to use Ruby2.0beta and another Vagrantfile for another project to use Ruby1.9, you essentially have two boxes, two execution environments, but you still code on the same machine.
taylorlapeyre 13y ago
User chewxy explained it well, but even more simply I just have two different versions of Ruby on my development box. 1.9.3 and 2.0.0.
awongh 13y ago
if nothing else is different, then you can still use rvm inside the VM. If they are different environments (one is a colo rack and one is an AWS instance) then you would want 2 vagrant boxes to more closely duplicate each environment.

chewxy 13y ago

Vagrant is the execution environment that you set up, share and whatnots. Your dev environment (IDE, text editor, etc) can still be in the original environment you are familiar with. For example, just yesterday, a colleague wanted access to Fork the Cookbook's source (he was supposed to be helping out on frontend javascript). But because some bits of the code is written to be Linux specific, he needed a Linux box while working on a non-Linux box. So I spent 30 mins creating a Vagrantfile, specifying the environment which Fork the Cookbook runs in. He takes it, runs the env, provisions with the existing provisioning script, and tadah, you get an environment where you get to run the code in. Due to the synced directories, you can code in whatever env you are hosting on: it's like dropbox between your computer and the virtual box. Network pass throughs allow your host (i.e your physical machine) to use networks defined virtually in your virtual computer. Great for sharing execution env and getting other people started. Not really necessary if you're working alone IMO

bosie 13y ago
> Vagrant is the execution environment that you set up, share and whatnots. Your dev environment (IDE, text editor, etc) can still be in the original environment you are familiar with. Sorry if i have missed this but how do you execute/debug in the IDE through Vagrant? e.g. how would rubymine use vagrant's ruby binary?
- lojack 13y ago
  In the case of any debugging in your IDE, you'd want to use remote debugging (which, I believe, rubymine supports). Otherwise, I'd connect to the virtual machine via ssh and debug there.
- chewxy 13y ago
  I'm not sure about Rubymine since I'm more of a Python/Golang guy (also I use SublimeText). In Python, there is an IDE called PyCharm that has a remote intepreter function. I expect all good IDEs to have something like that too: remote intepreter/libraries/etc EDIT: A quick Google yielded this: http://www.jetbrains.com/ruby/webhelp/configuring-remote-interpreters-via-virtual-boxes.html http://www.jetbrains.com/ruby/webhelp/configuring-remote-int...