The cookbook has been updated based on recent feedback. Also some requests from the previous pull request #2760 have been incorporated.

Hey @wcluijt!

Thanks for re-basing and re-opening this.

So that I don't make this drag out more, let me say why I'm leaning towards being 👎 on this, and then let's see if we can change my mind. Here are my issues:

• Assuming the goal is to help people easily get up and running with Vagrant (and know how things are setup), I think it would be much easier if we just provided a repository with all of the configuration they need. Because this looks like a lot of work. Then, they can just use that. Or to go further, why not just use Homestead (disclaimer, I haven't used Homestead yet, but I hear it's just a sensible VM, it's own project, and doesn't actually come with Laravel instead, so it can be used for anything - in fact it was used recently to show off the VarDumper component: http://www.sitepoint.com/var_dump-introducing-symfony-vardumper/)
• This includes Puppet, which is maybe fine, but it's a bit out of our scope. I'd rather tell people what they need to know about getting Vagrant and Symfony setup, and let them use whatever tool they want. But again, if there's an actual GitHub repository somewhere with a VM, that seems like the biggest win.

Thanks!

i fully agree with @weaverryan but symfony should provide a repository for using symfony + vagrant.

@weaverryan @timglabisch a new project related to this idea has just been published at https://github.com/karlosagudo/symvirins It'd be great if Vagrant people could check out the project and tell us what do they think about it.

@weaverryan Sorry for the wall of text in 3... 2...1...

I created the repository https://github.com/wcluijt/symfony-vagrant to test how this might work. The workflow is something like this:

$ git remote add symfony-vagrant https://github.com/wcluijt/symfony-vagrant.git
$ git pull symfony-vagrant puppet-ubuntu-precise32
$ cd vagrant
$ vagrant up

Or the other branch I made could be used:

$ git remote add symfony-vagrant https://github.com/wcluijt/symfony-vagrant.git
$ git pull symfony-vagrant puppet-ubuntu-trusty32
$ cd vagrant
$ vagrant up

Is this the kind of thing you were thinking of? It's the only one that I could come up with which should be fairly simple without disturbing an existing project too much. It depends on Git (and Github) though.

One of the scenarios I imagined when writing this cookbook was when a developer would choose to view the Symfony download page (http://symfony.com/download) and choose to download an archive rather than use Composer. With the new Symfony Installer that is being developed, having an archive downloaded might become a more common scenario. From what I can tell from downloading the Symfony archive manually and from looking at the current Symfony Installer code, it doesn't look like there will be a local git repository created automatically (it makes sense, who knows what kind of version control an individual developer may want to use).

So what happens when a developer doesn't immediately execute git init to create that local git repository for some reason (doesn't have git installed, doesn't know what git is, likes Subversion more, just testing and not using version control at the moment... who knows)? If there is no git command to handle the git remote add... example commands, then one thing that could be done is to have the reader copy/paste the Vagrant configuration code. I'm aware that in this Vagrant cookbook I chose as a prerequisite to have the reader use the "New Project using Git" cookbook which probably makes this scenario less likely, but that reference could be changed to the more recent Installation document which mentions using the Symfony Installer first.

I think I was trying to avoid using a repository because Vagrant configuration involves many different factors (base architecture, operating system, provisioning script type, shared folder type, different versions of software, etc.) and previous comments made in different pull requests seem to indicate that any defined configuration will not work for a majority of people, usually because one of those configuration aspects is not quite right or not exactly what they wanted (symfony/symfony-standard#407 (comment) ; symfony/symfony-standard#407 (comment) ; symfony/symfony-standard#407 (comment) ; symfony/symfony-standard#407 (comment) ; symfony/symfony-standard#407 (comment) ; symfony/symfony-standard#537 (comment)).

When you create a repository, I feel like a repository owner is stating something like "I have the answer to your problem" or "This will work for you", so with the number of Vagrant configuration options available, I imagine that this potential Symfony Vagrant configuration repository will need to store a lot of code to satisfy a good majority of the people who wish to use it. It reminds me of a repository I've seen which is related to creating Vagrant base boxes and stores a very large list of configurations (https://github.com/jedi4ever/veewee/tree/master/templates) based on the operating system version and architecture. Maintaining this kind of configuration repository itself seems like a lot of work. So if there was no repository to retrieve configuration files from, then the configuration would need to be provided in some other way, such as including it directly in the cookbook so that it could be copied and pasted into new files.

I think another reason I was trying to avoid using a repository was to prevent the user from wondering "Since I retrieved these files from somewhere else, is it OK for me to edit them?" With the copy/paste method where the reader is creating new files, I would hope that they get the sense that there really isn't anything standing in their way other than having knowledge about how to edit them in such a way where they get the configuration they want.

One reason that a developer may choose to use a Vagrant box for development is to have a way to model the production server configuration. If a developer's code executes successfully on a Vagrant box with one configuration, it should follow that a production server utilizing the same configuration will be able to successfully execute that same code as well (or at least that's the theory). With many of the provisioning script languages that Vagrant supports (Puppet, Chef, Ansible, etc.), it should be possible to execute them on the production server to configure it exactly.

For a developer who is just starting to work with Symfony, they probably don't care too much about what operating system and software is contained within the actual Vagrant configuration. If it works to display pages generated by Symfony, then they will probably be fine with whatever that configuration is. I suppose those that will be concerned with the specific aspects of a Vagrant configuration will be the developers who may have been working on a project for awhile and are ready to deploy to a certain production environment.

Based on symfony/symfony-standard#407 (comment) and symfony/symfony-standard#407 (comment) I tried to come up with a Vagrant configuration which would attempt to be very minimal, only including necessary items to create a traditional LAMP stack (which I assume is prevalent in many production hosting environments). I think only in very recent cookbook changes was something added which could be considered nice to have. So for developers new to Symfony and Vagrant in general, they may copy this Vagrant configuration without giving it a second thought and be on their way. A developer who has prior knowledge about the development environment they need or is somewhat familiar with Vagrant will most likely look very closely at the Vagrant configuration to determine if it satisfies their requirements and make changes to adapt it if they can. I suppose if a developer can do that, though, they might not really be the target audience of this cookbook.

When configuring Vagrant, I would say that there needs to be some kind of choice made about provisioning scripts at an early stage, otherwise the configuration doesn't do much of anything except create a virtual machine with a default operating system. When I started to write this cookbook, I didn't really choose Puppet for any particular reason other that it was the one I was most familiar with at the time. In terms of scope for Symfony, it would probably be out of scope to explain things like Puppet syntax and Puppet modules, which is best left to the Puppet documentation. But it would be kind of hard to not include Puppet code (or some other provisioning script language) when talking about a Vagrant configuration. In the cookbook, I think I tried not to explain it too much, maybe implicitly stating "See this huge block of code? Don't worry about it too much, just trust me right now and copy it into this particular file. Nothing will explode (yet)."

For Homestead (which I have not used as well), after a cursory view of the Github source, it seems like it is basically a wrapper around Vagrant commands with the intent to parse a YAML configuration file whose values will be provided to the Vagrantfile. Also, a certain base box is used which appears to have a list of software preinstalled (most likely to make the provisioning go faster). In that VarDumper article, though, it seems the author used their own fork called "Homestead Improved." For either Homestead repository, I didn't notice anything that would really prevent a Symfony site from running on it.

Anyway, I'm not sure if this convinced you otherwise, I was just trying to recall my thought process. I suppose you will let us know how you would like to proceed and I'll do my best to help.

@weaverryan can you please share your opinions on this?

Hey guys!

I'm sorry to be the blocker on this - I simply haven't had enough time (and don't have enough expertise) to get a reply back. I will say that I talked to Taylor yesterday, and he mentioned that Homestead now has Symfony support out of the box - thanks to laravel/homestead#243.

Homestead looks like an easy win. But I would be open to any proposal that can get the user up-and-running quickly. I'm still -1 on a huge article. There could be a mixture: if we showed how to use Homestead, there could be sections in that cookbook showing common customizations.

@wcluijt what do you and others think? Again, I'm very sorry for the complete silence - your wall of text was too great for me :)

Homestead is now documented in the Symfony documentation: #5655

What shall we do with this PR?

ping @symfony/team-symfony-docs

I am not sure. I don't like Puppet and I am not sure if this doesn't add to much confusion (and Vagrant can be used with a lot of other provisioning solutions).

I would also close this one as a won't fix. Homestead is a good solution, providing an out-of-the-box solution like Homestead or one based on Docker would be also better than documenting how to do it.

Hi @wcluijt! Thanks for starting this big and interesting discussion. As we now have documentation about homestead, I'm going to close this PR.

I hope I'll see you back with more great PRs in the future!