Open deizel opened 9 years ago
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.
Another relevant comment about not requiring the config file at all that would help solve this for us: https://github.com/puphpet/puphpet/issues/1356#issuecomment-74867421
The provided
config.yaml
seems rather bare bones.. which is unfortunate, because it doesn't seem to work (contrary to what the README suggests):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.