Wouldn't it be better to use a more standard base box, like the Ubuntu or Debian boxes served by Vagrant? That way upgrading the box later would be easier.

This is what we do in the MidCOM project template.

I would also opt for the vagrant base box.

There is no Debian Base box by vagrant, just Ubuntu ones. http://www.vagrantbox.es/ is not really something official, I guess I could easily put our box there as well ;)

But having said that, I don't mind using one of the Vagrant Ubuntu Boxes. Using our own, which we used in many other project already, was just the easiest and fastest way for me. And I'm way more used to Debian (and the dotdeb stuff for 5.4) than Ubuntu details.

So if anyone wants to change the config to use a base box from Vagrant with Ubuntu, feel free to send me a PR. I won't have the time to figure that out any time soon.

Cool. Do we still want to propose using Apache. Not that it can’t be changed, but defaults matter a lot as they set directions. Nginx anyone?

I think the main Vagrantfile should be called Vagrantfile.dist because people might need to change stuff (see comment by @adrienbrault about NFS), causing problems with update.

I don't know if there is another approach, we always use .dist files for this kind of stuff, telling developers to store a copy of the file without .dist. When something changes, one has to see the changes made to the dist file and either redo them in their local copy or skip them.

About nginx: we discussed that internally as well. And came to the conclusion that apache is much more widespread and especially the not so experienced people will know it much better and be able to do adjustments. Furthermore, just for development, it shouldn't matter that much. (that's also why I don't care that much, I'd be fine with nginx. It really depends what's the target audiance for this.)

@Sgoettschkes You'd have to .dist the whole vagrant directory with your reasoning. The chances are high that you'd want to do adjustments in one of those files as well, if you want to use it for more than just "Lemme check it out" but use it for serious development (and for example add another DB than just sqlite)

Which again doesn't mean that I would oppose to add a .dist. Just mentioning the pros and cons

@chregu That's true. I didn't thought about this.

Then there is the question if it makes sense at all to integrate it into the standard distribution. Maybe a stand-alone repository to fork and use would be better? Maybe we could add a section about vagrant in the cookbooks (or anyplace else in the docs)?

+1 on a standard base box.

I would guess the goal of this is to enable folk to easily get to grips with a Symfony installation, and having custom boxes and non-default repositories screams of added, and probably unnecessary, complexity to me.

As a user, I'd like to think that I had a slight chance of replicating this using standard, entry-level, methods.

@anthonysterling What do you mean with "non-default repositories"? The dotdeb stuff? Isn't that quite standard for recent PHPs in debian world?

Hey.

I just think it adds complexity where it's not required, dependant on the final choice of vanilla base box of course. Take the latest Ubuntu LTS release as an example, it ships with 5.3.10 and Symfony master only requires 5.3.3 (at time of writing).

I don't use Debian, and if the dotdeb repo's are required for this work in a "vagrant-ised" environment I'd say it should be replaced given other options.

+1 on a standard base box. (where you can can choose between 32/64/debian/ubuntu)
+1 upgrade of VirtualBox Additions
+1 for a php-build version of PHP (you choose php version in your Vagrantfile)
-1 for dotdeb
+1 for including mysql/phpmyadmin by default
+1 for xhprof

main_config.vm.share_folder "v-root", "/vagrant", ".", :nfs => (RUBY_PLATFORM =~ /linux/ or RUBY_PLATFORM =~ /darwin/)

should work in every case

@pborreli erm, no, even some linux distros do not come with nfs enabled by default. For Ubuntu 12.04 i.e. you still need to apt-get install nfs-common to enable the nfs support.

ah got it ! well it should be installed using puppet then, no ? nfs is giving so much speed that it should be enabled by default for all possibles VM/Hosts, what do you think ?

As indicated by the very vibrant conversation thus far regarding compatibly issues, is a default Vagrantfile + recipes the way to go, and is a bundle to generate interactively off the table?

Yes, doing everything entirely within Vagrant could mean your host machine is entirely free of PHP. But, it seems easier to say "install PHP and, if you would like to use Vagrant for local development, run ./app/console vagrant:init. Otherwise, build like normal!"

I would suggest that people create alternate PRs either from scratch or based on this one so that we stop discussing everything in abstract terms. Also it avoids us waiting for that magical unicorn that will solve every problem because then we never get anything except for lofty dreams.

I would suggest to NOT put vagrant configuration files into the standard edition but rather create a separate distribution for this.
Heaving this in the symfony standard edition might confuse and even scare new developers that just want to try symfony really quickly.

If on the other hand vagrant/puppet should be suggested as the default development environment, putting its configuration into standard edition would be great. In this case, it would be necessary to provide a really good documentation so people understand the benefits of adding vagrant and puppet to their environments and don't see it as a heavy weight overhead.

I started creating a project template with vagrant support based on symfony standard edition which is by far not stable (documentation is TBC, too) https://github.com/seiffert/symfony-vagrant. Feedback highly appreciated!

Maybe, if Symfony were to ever sanction using Vagrant officially, there would be a symfony-vagrant distribution one day :)

What do you mean by "sanction"? I think this should be possible by keeping this discussion alive and then providing a new distribution. User's will decide whether it is useful. If so, it will be recommended on symfony.com eventually. (That's just my naive opinion regarding how OSS development should work.)

Any updates on this?

Is there any edition with the vagrant config ready to be used?

I'm still using https://github.com/seiffert/symfony-vagrant for new projects. Although it is not really up to date in regards to composer deps, it is very handy for quickly setting up projects with vagrant VMs. Give it a try and maybe PR some updates ;-)

I agree with @lsmith77 let's get this merged and then we can improve upon it. Basics are basics, not everybody will use this so let's get over this one.

👍

👶

Any chance that it can be merged in symfony-standard as a vagrant branch?

Hi people, now a days we have a new custom vagrant box with https://www.puphpet.com/. I create my boxes with it and works good!

-1

IMHO don't think this should go in this repo. There is a lot of options to chose, distro, vmware/vbox, chef/puppet, ips, ports, nfs or not etc. And mix the App with the dev environment in the same folder is not the most elegant way.

In my case I use this structure …
app <---- Symfony here
cookbooks
…
Vagrantfile

I think this should go in other repo like symfony-sandbox not here.

I agree.

There are so many useful sites to make getting up and going with LAMP+Vagrant easy that the need for a "one size fits all" in the project is no longer necessary.

its not about one size fits all. its about getting going quickly and also to be newbie friendly

Then put in a link to a rove.io build in the docs. Bam. Done. Shoot, include a link to PuPHPet, too, and now everyone's happy!

Including cookbooks or manifests in the distribution is too opinionated on the stack and more cruft to remove when there's even a slight deviation.

@lsmith77 I think we have enough with the acme bundle… the symfony-standard is used I guess by 90% of us to start a new project. But I don't think that percent will use vagrant with a config that fits their requirements.

Only the discussion between puppet or chef will drop 50% of users, also the distro etc. So finally this will help only a few newbies and a few people that has made this PR because they've decided the setup.

So finally it will be "use my setup" or add more things to delete for start a new project

I think the https://github.com/symfony-cmf/cmf-sandbox idea for newbies is cleaner

Closing it now as I think this belongs to another repository and not Symfony SE.