Copy configs more often

[deizel]

I found I had to try multiple configs for a project before I was truly happy with the resulting VM, meaning I had to replace both puphpet/config.yaml several times manually. (I believe this only happens once when running composer install?)

Anyway, I was thinking one approach might be to inject some Ruby code into the Vagrantfile to handle this automatically when running vagrant up, though I would understand if this is something you wouldn't want to maintain.

The aim would be to overwrite the (non-versioned) puphpet/config.yaml with the (versioned) puphpet.yaml every time. Just putting it out there to get your opinion on the matter.

[beporter]

Yes, this is an excellent conversation to have. It gets pretty hairy pretty quickly of course, but until the puphpet project makes some changes to support this kind of use case, we're firmly stuck in no-mans-land already, so here we go!...

The idea of having the puphpet-release project dynamically modify the puphpet.zip package that it downloads from puphpet.com and stores in its release/ folder had occurred to us for a couple different reasons already. This is another good one, and might help solve #5 too.

The catch is to add to puphpet-release/bin/scrape-release.sh to modify the Vagrantfile that gets stored in the release/ folder. This is going to have to be pretty reliable, even when the Vagrantfile changes as the puphpet/puphpet project evolves. I'm open to suggestions on how best to inject new behavior.

There are lots of Vagrantfiles in the puphpet project and our code injection method needs to have a high chance of working with all of them.

Right now what that probably means is identifying a reliable "marker" line early in the Vagrantfile(s) after which we can safely add the proposed config-copying step. If this is successful, we would be able to remove the copy step from this composer installer.

There's more I could say, but I'd rather have a discussion about it. Thoughts?

[beporter]

I should also point out this feature request to allow for a configurable config file location: puphpet/puphpet#1429

That would honestly start to solve the problem a lot more elegantly. And I'd much rather push improvements up the chain into the Puphpet project than into these "hack" projects so everyone can benefit.

[beporter]

Just to get things linked up, this is also a bit of a duplicate of phpfu/puphpet#7.

[deizel]

There are lots of Vagrantfiles in the puphpet project and our code injection method needs to have a high chance of working with all of them.

Assuming we aren't interested in the internals of the Vagrant file (variables/requires/etc), I would say injecting something at the very top of the file might be best (before every other line in the file).

This way, we can just do whatever we want initially (in plain old Ruby), then get out of the way (that is to say, after our code, starts the "Vagrantfile").

A small footprint is probably best, so perhaps a single line of code (if possible) such as:

load "vendor/puphpet-release-composer-installer/src/Loadsys/Composer/copy_files.rb"

The catch is to add to puphpet-release/bin/scrape-release.sh to modify the Vagrantfile that gets stored in the release/ folder.

The approach I'm suggesting (loading an external script) would likely need handled by the composer installer script, as we won't know the correct vendor path until then (since this is a configurable value in composer.json).

Better yet, use PHP:

system "php vendor/puphpet-release-composer-installer/src/Loadsys/Composer/PuphpetReleaseCopier.php"

This could be a unit-tested script that does everything required for this and related tickets (overwriting the config.yaml, the files/ folder, etc.) and would run on each vagrant invocation. Thoughts?

[beporter]

That's a novel approach. For some reason, in my head I always envisioned the puphpet-release project as being the "heavy" part of the pair. That it would scrape a new puphpet.zip file, modify it for use with composer, and commit/push the adapted file set back to the repo. The puphpet-release-composer-installer in contrast was only going to be enough code to address the unchangeable aspects (like putting the Vagrantfile in the consuming project's root.) Your alternative approach of leaving the puphpet-release project more or less "stock" and performing all of the necessary modifications during installation never occurred to me, to be honest. It does make a certain amount of sense.

I'm happy that we'll be able to remove PuphpetReleaseInstaller::copyConfigFile() entirely. And we'd open the door for injecting other necessary behavior modifications via that "bootstrap" script at the top of the Vagrantfile. I'm torn on php vs ruby though. I think using ruby might offer better long term advantages by allowing us to call Vagrant methods directly if the need ever arose. Ruby is just as testable as PHP, and I think I'd rather complicate the Travis environment than the codebase-at-large. In other words, I like your load "..../bootstrap.rb" idea a little better.

I'd like to believe that this all will ultimately only be needed as a patch, and that the Puphpet project will eventually support a more "compatible" folder structure out of the box, but until then this is a reasonable plan in my book.