Great @wcluijt ..thanks a lot!

Thank you for creating this article. I have no knowledge about vargant and this article looks a bit 'dummy copy past'. I prefer to have create guides in the symfony docs which really explains what the code means, does and why we need it. Is it possible to transform this article in such way?

You should also include a link to this article in components/map.rst.inc

@wouterj Yeah, I think the main intent of the article I had was something like "copy/paste, run these commands exactly, get something cool." :)

One thing I didn't really want to do was to get so much into the explanation of the third-party systems involved that it overshadowed the main task of creating files and executing some commands. But, more explanation can't hurt.

What kinds of questions initially came up for you when reading this? Maybe I can focus on answering those.

Also, you meant the cookbook/map.rst.inc file, right?

@wcluijt Could you also include improvements from my comments to symfony/symfony-standard#537?

Hi guys!

I need to run through this entry, make sure it works, and add any necessary notes.

But before I do, have we thought about pointing people to https://puphpet.com/quickstart/symfony and collaborating and improving the options there instead of having this doc? Or alternatively, point to that link then explain some extra or advanced notes in this doc?

What do you guys think?

@weaverryan When I initially created this document, I don't think that particular PuPHPet page existed yet. So including a link to it sounds great to me! And they should be able to handle all kinds of cases, such as @maxromanovsky's comment about Apache EnableSendFile symfony/symfony-standard#537 (comment) which appears to be handled in PuPHPet already.

guys it has been 4 months already and https://puphpet.com/quickstart/symfony is a 404 now

and i see no signs of website repo here https://github.com/puphpet and no wonders, i think we should keep this PR because it easies integration with symfony, just adapt it to help the generic PHP docu.

I have always rejected vagrant even when using it, but I am willing to run down and test it by hand if it is the case. And maybe add a blog post on craftitonline.com about my experience :P if it is good now

other than that good job @wcluijt , keep pushing it

Indeed, the puPHPet page is gone. What's the status of this @wcluijt @weaverryan, can it be merged? Do you want more opinions of Vagrant experts? ...?

I went over the configuration again and pushed some new changes. The changes relate to the Apache and MySQL Puppet modules changing their syntax since I last checked some time ago. Other than that, I think it can be merged.

Great, thanks for your work on this @wcluijt !

Hi guys!

Sorry for the delay, I've been thinking about this. I do think this is a good entry. But, why not actually create a repository (or adopt an existing repository) that actually contains all of this setup completely done? We could then include all kinds of information inside that repo's README for how to configure X or do Y. This entry could then basically point you to that repository. This would allow us to create a much much better user experience (imagine setting all of this stuff up manually) and would allow the community to add more features/options to that setup to make it better and better.

Thoughts? Are there clear existing leaders that would be good to recommend?

ping vagrant experts?

This is a great PR and something that can help beginners a lot.

A little history about my experience with Vagrant and puppet. This is a little off topic and is more in response to @wouterj and @weaverryan to give some insight into experiences that I've had with Vagrant.

My team was using puphpet for sometime up until recently when I came across http://laravel.com/docs/homestead. While I thought puphpet and puppet in general was great, it really over complicated things as I look back. Puppet in generally is great for machine provisioning, but you can do things a lot easier without it.

For one, it introduces a new syntax that many people are not used to. Another obstacle with it is the learning curve it comes with in general. I thought this could easily be handled, but as time would show this was not the case. Getting new developers into the puppet files to have new things installed often encountered challenges and a lot of digging around for what puppet modules and syntax to actually use.

To add to the complexity of puppet, I stumbled across puphpet which I thought was a great tool to use; however as time would tell again we had problems with that as well. It was great to use the web interface to add things or reconfigure the box, but it often had BC problems as the project currently has no tags. You can imagine the problems that come with little BC support in larger teams. You can also take a look at some recent issues for experiences that people are having with that; hopefully this gets better over time. I will say that I'm sure there are ways to get around this, but I'm going for simplicity and I had too many team members having problems with puppet which was not needed.

As I said above, I recently stumbled across the Homestead project and I think this is a good example of how this article should be tailored.

Few things I like about it are:

• It uses shell provisioning which makes it extremely easy for people to get into the project and customize it how they need.
• It manages vhosts with simple shell scripts such as https://github.com/laravel/homestead/blob/master/scripts/serve.sh.
• The amount of time it takes for that project to launch and provision the VM is less than 5 minutes in most cases where as using an image from puphpet took much longer.

Overall, I think this is a great start and something that should be added to the docs ASAP, however I would challenge people involved with this to take a look at Homestead. I've got a version working with apache that also supports ssl and is running multiple Symfony2 based projects right now. If people are interested I can publish this version.

I'm curious to hear what others have to share and going on what @weaverryan said in his latest comment, I think we should follow an approach similar to Homestead and add articles on how to customize it more. There is no need to re-invent the wheel and I feel Homestead has made it extremely easy to get Vagrant running and PHP project running inside of it. Granted I'm not saying puppet is bad, but I am more for getting people started with shell based provisioning as it's easy for most to see whats going on at first and customize without digging through many docs IMO. Now on the flip side, the Homestead project does not create any databases for you with provisioning but it's makes it very easy to connect the the DB in the VM so you can do what you need which in general I think is a better approach unless your using it for very specific projects such as what Sylius has done.

I rebased to the 2.3 branch. I also created a new pull request: #4676

Thanks @wcluijt - I'm closing this in favor of #4676