Figure out how to handle PuPHPet `files/` folder.

[beporter]

Currently the installer only copies in a puphpet.yaml file, if found. This leaves a big chunk of PuPHPet's customization unavailable since there's no automatic integration for the puphpet/files/ folder.

My current best suggestion is to mirror how we handle the /puphpet.yaml ➡️ /puphpet/config.yaml copy step, but for the normal /puphpet/files/ directory as well. This would have to be a merge, to ensure that anything that comes "stock" from PuPHPet gets installed first, then possibly updated by the consuming project's version of the folder.

There may also be an issue with the SSH keys that are generated. When someone composer updates an existing installation, we don't want to wipe out the key files that were created in the target directory. Since we currently don't purge the existing directory it might not yet be an issue, but really we should be syncing "deletes" from the upstream PuPHPet release into the installed folder too. When that happens, the ssh keys would appear to need to be deleted since they wouldn't exist in the release/ folder we copy from. They'll need to be preserved somehow.

[beporter]

As a more general principle, it might also be possible to allow the consuming project to define an override file for any file normally supplied by puphpet-release. So basically:

When you run composer require loadsys/puphpet-release:1.0.0,

• Copies vendor/loadsys/puphpet-release/release/puphpet/ to puphpet/
• THEN copies puphpet-overrides/* from the consuming project on top of puphpet/, overwriting any matching filenames.

The benefit being that you could override or "patch" anything you wanted from the release/ folder.

But, this is getting pretty complicated, and this introduces the problem that your override copy of a file won't get updated as puphpet.com issues new releases upstream from us. This could introduce a breaking change that would have to be addressed separately from the composer update process we're trying to consolidate this whole process down into.

[ricog]

If we can limit our changes to scriptable changes (such as re-adding the
vagrant password), we could just use exec and startup scripts to handle
customizations. That way no actual puphpet files get altered. Then it is
just a matter of copying the exec and startup files into place each time.

On Wed, Mar 11, 2015 at 11:28 AM, Brian Porter notifications@github.com
wrote:

As a more general principle, it might also be possible to allow the
consuming project to define an override file for any file normally
supplied by puphpet-release. So basically:

When you run composer require loadsys/puphpet-release:1.0.0,

• Copies vendor/loadsys/puphpet-release/release/puphpet/ to `puphpet/'
• THEN copies puphpet-overrides/* from the consuming project on top of
  puphpet/, overwriting anything that conflicts.

The benefit being that you could override or "patch" anything you wanted
from the release/ folder.

But, this is getting pretty complicated, and this introduces the problem
that your override copy of a file won't get updated as puphpet.com issues
new releases upstream from us. This could introduce a breaking change that
would have to be addressed separately from the composer update process
we're trying to consolidate this whole process down into.

—
Reply to this email directly or view it on GitHub
#5 (comment)
.

Rick Guyer
Project Manager
Loadsys Consulting Inc.
Email: rick@loadsys.com

[beporter]

I think that's a very reasonable compromise.

The only issue I can think of with that approach is that if any of the puppet manifests needed tweaking it could get ugly or impossible. Although, part of the point of hosting our own copy of puphpet.zip (as the puphpet-release package) is to make that kind of modification there instead. By the time composer delivers the manifests from loadsys/puphpet-release, they should be in a ready-to-use state.

In theory that kind of thing should be addressed even further upstream in puphpet/puphpet anyway, but in practice there's still a few things we need to "fix" post-download that will be a struggle.