Vagrant Bundle Laravel Package

Getting Started

This is a Symfony2 console bundle, not a Laravel package — treat it as a scaffolding generator rather than a runtime dependency you ship in composer.json of a Laravel app. Its entire job is to write a Vagrantfile you then own and edit.

Minimal steps:

1. Install it as a dev dependency in the Symfony2 project that actually uses it:

   composer require --dev ericclemmons/vagrant-bundle
   

   (If it isn't on Packagist under that name, add the VCS repository entry pointing at github.com/ericclemmons/ECVagrantBundle and require the dev-master constraint.)
2. Register the bundle in app/AppKernel.php in the dev environment only:

   if (in_array($this->getEnvironment(), ['dev', 'test'])) {
       $bundles[] = new ECVagrantBundle\ECVagrantBundle();
   }
   

3. Run the generator from the directory where you want the Vagrantfile to live:

   php app/console generate:vagrant
   

4. Answer the prompts, then vagrant up.

Where to look first: the command class inside the bundle (Command/GenerateVagrantCommand.php or similar) and whatever Vagrantfile template/skeleton it renders. The README only documents the CLI surface, so the command source and the template are your real reference — the generated file is the deliverable.

First use case: onboarding a developer onto a legacy Symfony 2.x app that needs PHP 5.3/PHP 5.4 and can't run on their host machine. You run the generator once, commit the resulting Vagrantfile, and the whole team gets an identical VM. From a Laravel perspective, this is conceptually Homestead — a per-project VM definition generated from a recipe.

Implementation Patterns

1. Interactive first, scripted second. The intended workflow is: run php app/console generate:vagrant once with prompts, inspect and hand-edit the Vagrantfile, then stop using the generator. Re-running it later will clobber your edits. The non-interactive form exists to reproduce a known-good setup, not for repeat runs:

php app/console generate:vagrant --no-interaction \
    --host=vagrant --ip=10.33.33.33 \
    --url=http://files.vagrantup.com/lucid32.box

2. Wrap the generator in a project bootstrap script. Because the flags are explicit and the output is deterministic, a bin/setup-vm.sh that pins --host/--ip/--url is a reasonable way to keep a team aligned on a single IP and box:

#!/usr/bin/env bash
set -euo pipefail
php app/console generate:vagrant --no-interaction \
    --host=myapp.local --ip=10.33.33.33 \
    --url=http://files.vagrantup.com/lucid32.box

Then commit the Vagrantfile and treat the script as a reset button for a fresh checkout.

3. Commit the Vagrantfile, ignore the VM. The generated file is source. .gitignore the .vagrant/ directory and any synced app/cache, app/logs, vendor/ inside the shared folder. Symlink or mount vendor from the host if you want composer runs to stay fast.

4. Pair the VM with the app's config, don't fight it. Set --host to a hostname your app/config/parameters.yml (or config_dev.yml) can resolve — e.g. database_host: myapp.local — so the same parameters.yml.dist works on host and guest. That's the main integration tip: the generator's only meaningful coupling to your app is the hostname/IP you put in parameters.

5. If you're on Laravel, port the idea, not the package. Laravel has no AppKernel to register a Symfony bundle into. Either (a) copy the Vagrantfile template out of this repo and use it as a starting point in a Laravel project, or (b) just use Homestead / laravel/sail. Installing a Symfony2 bundle into a Laravel app buys you nothing.

6. Use it as a template library for your own generator. The bundle is small; if you like having a generate:vagrant command, re-implement it as an Artisan command (php artisan make:command GenerateVagrantfile) that renders a stub — the pattern is a good fit for Laravel and takes ~30 lines.

Gotchas and Tips

• It's Symfony2-era and effectively unmaintained. PHP 5.3+, Symfony 2.0–2.3 era conventions (app/console, AppKernel). It will not install cleanly against Symfony 4+/5+ without conflicts, and 0 dependents on Packagist is a signal: nobody is keeping this current. Don't plan a migration onto it; plan a migration off it.
• lucid32 is a dead box URL. The README's example points at the old Vagrant lucid32 image, which has been retired from files.vagrantup.com. vagrant up will fail with a 404 or checksum error. Substitute a live box (or a locally added one) before you rely on the example — this is the single most likely first-run failure.
• Output directory is your CWD. It writes Vagrantfile in the current working directory, not the bundle's or the project root. Run it from the repo root or you'll get a stray Vagrantfile one level off. There's no --path/--output flag documented.
• Non-interactive mode needs every option. With --no-interaction, any omitted flag (host/ip/url) can't be prompted for. Script your wrapper with all three pinned, and add -v to see the actual command/error if it bails.
• Re-running overwrites. There's no merge or “file exists, skip?” logic documented. Back up or commit before regenerating; treat it as a one-shot scaffold.
• IP collisions. 10.33.33.33 is a shared convention — if two projects on the same machine both use it, only one VM can be up. Give each project a distinct IP in its wrapper script.
• Box vs. provisioning. The bundle generates the Vagrantfile (box, hostname, IP, network), not Puppet/Chef/Ansible provisioning. Anything beyond “a vanilla PHP box on the network” — installing PHP extensions, MySQL, composer, running the Symfony app — is on you, inside the Vagrantfile's provisioner blocks.
• Debugging: run the console command with -v/-vv to surface exceptions (it's a standard Symfony console command), and validate with vagrant validate before vagrant up. If the generated file looks wrong, diff it against the template in the bundle's Resources/ — the template is the source of truth.
• Extension points are thin. The realistic customization is: (1) copy the template, (2) subclass or re-implement the command, (3) edit the generated Vagrantfile by hand. There's no documented config tree in the bundle, so don't expect to configure it via config.yml — the CLI flags and the template are the whole API surface.
• Verdict for a Laravel dev: useful as a reference implementation of “generate an environment definition from a console command,” and useful if you've inherited a Symfony 2.x app that needs a VM. Not something to add to a Laravel composer.json, and not a Homestead replacement.