search

phpfu / puphpet-installer

Provides a composer custom installer that works with `loadsys/puphpet-release` to add a PuPHPet.com vagrant box to a project via composer.
MIT License
2 stars 1 forks source link

Re-thinking the approach #14

Closed deizel closed 9 years ago

deizel commented 9 years ago

I've been using this as a way of distributing development VMs for a while now, and while it has several limitations I still find it more convenient than committing the PuPHPet files into the same or separate repos. Though a quick glance through recent changes to your Skeleton app-template has me believing you may have changed strategy for your internal stuff and no longer have plans for this?

Anyway, I had some time yesterday to start looking through some of these limitations, such as moving the config file to the right place and how to manage the files sections...

I started by trying to symlink the config file instead of copying. Of course, this is a complicated topic in itself because Windows (it seems possible on some versions, if you accept the elevated permissions dialog, but I didn't have a box handy for testing). So I wrapped symlink() in a try/catch with the usual copy step as a fallback, it was working in the integration tests, but I had less luck with it in an actual project and didn't investigate further. (https://github.com/deizel/puphpet-release-composer-installer/commit/2175cced7cd4c4533e5bf1559242d0a32b8a54b4)

I then moved onto to thinking about how to manage the /puphpet/files folder. As a test, I had a shell script I wanted to copy into the exec-once-unprivileged directory, however I immediately found that having another folder, such as /puphpet-custom/ or /.puphpet/ that held files available for switching into place (via symlink or mirror) wasn't exactly to my taste (or I wasn't up to the challenge).

Ultimately, I ended up deciding not to fight PuPHPet's default folder structure, deleted the default config.yaml that ships with the release (https://github.com/deizel/puphpet-release/commit/2e228c178dfa34bfeaa647b28a93bb2cbc62cd01) and allowed puphpet/config.yaml as well as the entire puphpet/files/ folder (minus the dot) folder to be versioned (https://github.com/deizel/puphpet-release-composer-installer/commit/aa64d3ad84465e8e34c0f364877b131b62a42103).

This means the .gitignore rules that are managed now look like this:

/.vagrant/
/puphpet/files/dot/
/puphpet/puppet/
/puphpet/ruby/
/puphpet/shell/
/puphpet/vagrant/
/puphpet/config-custom.yaml
/Vagrantfile

And files such as these are allowed to be versioned:

/puphpet/files/exec-once-unprivileged/dotfiles.sh
/puphpet/config.yaml

In summary, my changes do away with the root puphpet.yaml in favor of the intended config location, there is no longer a needed to move files around (https://github.com/deizel/puphpet-release-composer-installer/commit/642ea8885e7faab52944c036a46b0352f9dca34a), and by deleting the default config.yaml there isn't a chance of it getting wiped out during updates.

While not the holy grail, I do feel that taking this approach sidesteps many of the open issues, making things more immediately customizable (you can commit shell scripts, your config.yaml, and have a config-custom.yaml, all in the default locations). Happy to continue with my own fork(s) for the time being as they work for me (thanks to your initial hard work), but posting here really to get your thoughts on this approach and inquire about the status of the project.

See also: https://github.com/gourmet/platform/pull/12

beporter commented 9 years ago

I do feel that taking this approach sidesteps many of the open issues, making things more immediately customizable (you can commit shell scripts, your config.yaml, and have a config-custom.yaml, all in the default locations).

Yeah, your approach sounds like a pretty good solution and mirrors how Cake's app skeleton works pretty nicely (you have to manually import changes from the upstream webroot/index.php into your projects for example.)

Though a quick glance through recent changes to your Skeleton app-template has me believing you may have changed strategy for your internal stuff and no longer have plans for this?

You're correct about this. We've decided to ditch puphpet completely in favor of extremely light weight shell scripts tuned for a single common dev/hosting environment. The overhead wasn't worth it for us any more, and the speed improvements in provisioning the boxes has been a nice boon.

Would you have any interest in taking over the two repos? This and the puphpet-release project? There will be a little bit of work involved since the composer package names will need to change their vendor prefixes but I'd be happy to help coordinate that and transfer the Github projects over to you. They deserve to live with someone who can give them the :heart: and attention they need and not languish untouched and abandoned. And of course it would avoid any possible confusion over the forks in the future. Our only request would be that you continue to include an attribution line in the README pointing to loadsys.com as initial contributors. (The boss is keen on that.)

deizel commented 9 years ago

We've decided to ditch puphpet completely in favor of extremely light weight shell scripts tuned for a single common dev/hosting environment.

Cool, I didn't get a chance to look in great detail but it makes sense to unify the environments (dev/prod/etc), especially if you know ahead of time what you're dealing with (mostly AWS in your case?)

Would you have any interest in taking over the two repos? This and the puphpet-release project?

Sure, I somewhat expected you might ask. We would be more than happy to take over maintenance if you are now focusing your efforts elsewhere. :grinning:

I say "we" since a couple of us have started an org to host repos aimed at PHP development tools, workflows, environments, etc. We've rolled out a few projects in the last few days and there is more in the pipeline.

I think https://github.com/phpfu could make a nice home for the project(s) and give them more exposure than my personal account ever would.

Our only request would be that you continue to include an attribution line in the README pointing to loadsys.com as initial contributors.

Definitely, this is how OSS rolls. I'll be on #phpfu if you want to discuss further, or just hit the transfer button in your own time. :)

beporter commented 9 years ago

Alright, I think we're all on the same page then.

In order to transfer a repo from one org to another, someone needs to belong to a Team with Admin privs in each org. GiHub's suggestion is for the receiving org to create a new Team with Admin privs and zero repos and add a person from the sending org to that Team.

Would you mind creating a temporary Team in your phpfu org with admin privs and adding me to it? I'll shunt both repos over to that team and then remove myself. The rest is just going to be minor clean up work (changing the name in package name composer.json, asking Packagist to delete the old package, updating links, etc.)

beporter commented 9 years ago

Okay, that should do it for the GitHub side. I'll leave the rest of the tweaks up to you, but do please let me know if I can be of assistance with Packagist. I know from experience that you have to email them or post an issue to have a package removed, and you may have problems since the package's vendor is still listed as loadsys on their site. I'll be happy to send the deletion request email if you like.

deizel commented 9 years ago

Great! I've made the necessary changes at our end and submitted to Packagist. We also took the opportunity make the package names a bit shorter:

FWIW, the suggested approach seems to be editing your packages repository URL on Packagist and then deprecating the package, but do as you see fit: https://github.com/composer/packagist/issues/496#issuecomment-131521262.

I'll tidy up the README.md files when I have some more time and make sure credit is given where due. :)

beporter commented 9 years ago

Ah, okay. That's improved since the last time I had to do it. All done:

deizel commented 9 years ago

Awesome - thanks for the smooth transition and all your hard work so far!

We will make sure to give the package(s) a bright future! :rocket: