Default config file

[deizel]

The provided config.yaml seems rather bare bones.. which is unfortunate, because it doesn't seem to work (contrary to what the README suggests):

$ touch .gitignore
$ composer update
$ vagrant up
# snip
==> default: Error: Cannot reassign variable apache_values at /tmp/vagrant-puppet/manifests-893fcda21077f5a583c2dbbba8515c0a/nodes/Beanstalkd.pp:4 on node packer-virtualbox-iso-1422588891.vagrantup.com
==> default: Error: Cannot reassign variable apache_values at /tmp/vagrant-puppet/manifests-893fcda21077f5a583c2dbbba8515c0a/nodes/Beanstalkd.pp:4 on node packer-virtualbox-iso-1422588891.vagrantup.com
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.
>>> elapsed time 1m37s

I would have expected a default similar to that of first visiting the PuPHPet website.

That is, with Nginx/PHP/MySQL installed, and having a single vhost and database.

I haven't had a chance to look at this so I'm just leaving an issue for now.

Maybe uploading a config (as you do when you use the HTML5 drag & drop to upload existing configs to their website) would allow us to get something more useful back as a default.

[beporter]

This is mostly intentional, actually. That config file actually only exists to prevent vagrant global-status from breaking, believe it or not.

The problem is that where the web app running at puphpet.com initializes with a set of "defaults" that allow you to click all the way through the wizard without making changes and still end up with an operational box at the end, the way we fetch the puphpet.zip file doesn't afford us the same luxury. It might be worth experimenting with POSTing an existing "default" config.yaml file when we curl the puphpet.zip file, but even this file would quickly become out of date and need constant (manual) updating. That's not something I'm looking forward to, personally.

We don't really have a choice but to instruct users to manually configure their own config.yaml using puphpet.com and save it as PROJECT_ROOT/puphpet.yaml separately. Unless we want to duplicate the entire Puphpet web wizard as a console application that could prompt the user for choices during the composer require loadsys/puphpet-release process (something I've asked Juan about), I'm not sure we have a good long-term solution to this. I'm open to suggestions.

[beporter]

Another relevant comment about not requiring the config file at all that would help solve this for us: puphpet/puphpet#1356 (comment)