search

loadsys / CakePHP-Skeleton

Base CakePHP 3.x and 2.x project skeletons for new projects.
10 stars 1 forks source link

Decide what to do for this for CakePHP 3.0 #16

Closed justinyost closed 9 years ago

beporter commented 10 years ago

Last I read, the general idea for Cake was going to be something like this:

  1. Clone a "starter" app repo (not the Cake core project).
  2. Run composer install to load a copy of the core into the correct place.

Assuming this is still the general idea, then my initial thought is to either mimic the starter repo but fully maintain our own internal copy, or fork it and manage the process of importing/merging the core team's updates as well as our own customizations.

Thoughts on this?

joeytrapp commented 10 years ago

Maybe a generation tool we could give back to the community?

beporter commented 10 years ago

For reference, here are the "Installation" docs for 3.0: http://book.cakephp.org/3.0/en/installation.html

justinyost commented 10 years ago

Yeah based on the docs there is going to be a primary way to go with composer:

php composer.phar create-project --prefer-dist -s dev cakephp/app will give you a fully built Cake 3.0 app ready and waiting (permissions and everything)

We could copy all of the things created in this create-project command and merge in our vagrant and various other improvements (custom composer/travis/etc) and have something probably close to what we have now.

beporter commented 10 years ago

Yeah that's what I was thinking too. Essentially, all of our additional "conventions" would be in replacing the cakephp/app part of that command line with our own loadsys/cake-skeleton.

That still leaves the question of whether we should track the official repo or maintain our own independently. (Tracking is the way I'm leaning since it's like that app repo will get a lot of attention initially that we can leverage "for free".)

joeytrapp commented 10 years ago

https://getcomposer.org/doc/03-cli.md#create-project

That is interesting. To my knowledge, other package managers don't have this (npm, gems *bundler might). Forget I mentioned tooling, as this should suffice.

justinyost commented 10 years ago

Just as an fyi, I did the create-project last night in working through my composer talk. It worked like a charm, Cake3.0 project in one command and 30ish seconds.

beporter commented 10 years ago

The cakephp/app repo is still currently listed as alpha, but that doesn't surprise or bother me right now. Anyway, take a look at it to see what all they include.

For comparison, here's a (rough) list of the items I've customized in our current Skeleton that we'd want to replicate in some way for 3.0:

beporter commented 10 years ago

One complication might be whether we are comfortable with our skeleton being open source. Composer might have trouble running the create-project command on a private repo (although if your local git install already has access it might not be an issue.)

At the very least, we should experiment with composer create-project using a new branch in our Skeleton repo here with the minimal composer details included.

justinyost commented 10 years ago

composer create-project seems like exactly the right way, since it will auto-load depencies and can run scripts post setup to get everything going correctly (move configs, set permissions, etc)

beporter commented 9 years ago

Turning this into an Enhancement: We should start a 3.0 branch and begin setting it up for testing this approach (as time allows, of course.) Using proper release tags should allow us to add this repo to Packagist for 3.0 use without having to create a new repo (since the purpose is the same but the approach in-code is just different.)

beporter commented 9 years ago

I was poking at setting up a Cake 3 app skeleton today, and the first challenge I've run into is one we've seen before. Just running composer create-project requires that you have a minimum required PHP version install on your host system (currently 5.4.19). This includes all PHP extensions named by package dependencies. My Mac's MacPorts-installed copy of PHP didn't have the intl package installed so the command failed.

I don't particularly want to continue to have to maintain an entire PHP ecosystem on my host system solely for the purposes of satisfying composer.json dependencies when the code I'm pulling in will never be run anywhere except inside a (bundled!) vagrant environment. Running the composer command from inside vagrant is a non-starter for two reasons:

  1. The vagrant configs are part of what I'm trying to pull down via create-project.
  2. Even assuming I had a virtual environment with PHP + extensions + composer available, and mapped to the correct local filesystem location on my Mac, Having composer run inside the VM would be limited by the (typically horrible) host<-->guest shared folder I/O speed.

I don't have an elegant solution for this in mind. Ideally the composer executable could be somehow told to ignore PHP and extensions requirements, but that doesn't seem likely to me. And I'd like to see a copy of composer available as a "native" executable so I don't need that otherwise-pointless PHP ecosystem on my host, while I'm making a wishlist.

Either that, or we need to consider a different mechanism for pulling a fresh project skeleton onto our development machines and setting it up for use. Perhaps something along the lines of how some tools suggest you fetch and execute a script from a remote URL? (Bonus Tumblr entirely of examples of this practice.) We could bundle a plain shell script with our skeleton that did the bootstrapping for us, and include the proper invocation line in the Skeleton's README. Setting up a new project would consist of copy/pasting the invocation onto your local command line and executing (or aliasing the command locally). Of course this doesn't necessarily get around needing composer installed on your host to work around I/O speed issues though...

Thoughts?

beporter commented 9 years ago

Transcribing from Slack chat:

  1. If composer can be compiled into a native binary, it could be used on the Mac host without the associated PHP ecosystem, and allow us to use the composer create-project method for spawning a new project skeleton.
  2. If composer is run inside the VM (which may require the dev's github token, another wrinkle), but it's run on a non-host-shared folder, then I/O performance will be extremely good. We'd need some kind of post-processing move/copy/share step to make the project installed in the VM available to the host system then.
  3. We don't use composer from the hosts at all, and use some other mechanism to kickstart new projects using our Skeleton, like curl http://github.com/loadsys/skeleton/bootstrap.sh | sh. (We'd still need to run composer inside the VM to install/manage dependencies though of course.)
  4. We find an alternative solution to poor VM shared folder I/O performance, which would kill a bunch of other birds with one stone, but this is probably the hardest path.
  5. We just keep maintaining PHP ecosystems on our Macs for the single purpose of running composer, and deal with version/extensions conflicts as they occur. (blech)
beporter commented 9 years ago

Idea from Rick related to 2 and 4 above:

Inside the VM, symlink the /var/www/Vendor folder to a non-shared (VM-internal-only) folder such as /var/composer/Vendor and then run all composer commands from inside the VM. Since composer wouldn't be installing deps to a shared folder (that would exhibit poor I/O performance) it should run quickly enough.

This wouldn't help for things like running a grunt test watcher (which again we typically do on the host for the same performance reasons), but it's a start.

beporter commented 9 years ago

In the short term, this recently-added composer command line switch may be of use: --ignore-platform-reqs.

beporter commented 9 years ago

Making a note of a side effect. When the database.php file makes use of the Configure class to read settings, it can no longer be manually included in other PHP scripts, such as bin/db-credentials due to the Configure class not being available. Additionally, adding App::import('Core', 'Configure'); or App::uses('Configure', 'Core'); is not sufficient either since the App class is likewise unavailable.

The only way to work around this is to use the ConfigReadShell plugin to provide command-line access to Configure arrays. The EU legacy project has hardcoded bin scripts, so they've already been directly updated to use this approach and can be used for reference.

beporter commented 9 years ago

Closing this conversation, as we've made our decision on how to move forward:

The fork of cakephp/app that existed as loadsys/app where Andrew did some invaluable initial experimentation and improvement will be retired, and migrated into loadsys/CakePHP-Skeleton's master branch. The existing Cake 2.x compatible skeleton will live on in a mostly-archived and for-reference state in the permanent cake-2.x branch here.