Offering bundled composer packages in 3.0

[Jose Diaz-Gonzalez]

I was just thinking that if we went full-on composer, it would be nice to allow people the option of selecting subpackages they'd want included in their download.

For example, we could provide a ui that is something like:

[x] core [ ] core tests [ ] debug_kit [ ] migrations [ ] crud [ ] acl [ ] console

We could write a very simple script to pre-generate all the options and store them on the server. Could then write a ui that would automatically choose the correct option from our server - or host on s3 - for the specific CakePHP 3.x release.

Twitter Bootstrap and jQuery UI both provide something similar to what I am trying to describe, in case there are any ambiguities.

Does anyone have any concrete thoughts on this? It sort of solves our packaging issues.

As an addendum, it could be very cool to allow people to pick out community plugins they want in their download (would build a composer.php file, for example) like what RailsWizard does with rails templates. I'd be extremely happy to build this if anyone is interested.

Jose (little)

[Renan Gonçalves]

I really like the idea.

It indeed would solve our packaging problems like you mentioned. Plus bring more attention to plugins that helps a lot at development (eg: DebugKit) and deployment (eg: Migrations).

At the end, would it provide a .zip package or just a composer.json file?

Having a composer.json file is something I see myself using to quick start a project.

I assume the plugins will be gathered from github.com/cakephp, meaning core plugins? Pushing a unknown plugin maybe dangerous.

--
You received this message because you are subscribed to the Google Groups "cakephp-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cakephp-core...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Renan Gonçalves aka renan.saddam
Software Engineer at TrueServer B.V.
CakePHP Core Developer

W: renangoncalves.com

T: twitter.com/renan_saddam

M: +31 (0)6 4662 1860

L: Amsterdam, The Netherlands

[Ravage84]

Certainly an intriguing idea.
But even though it would certainly be a cool thing I wouldn't go that way with the plugins.
I mean there are so many interesting and useful plugins and their numbers are increasing.

I personally would love to see something like a PEAR shell for installing, updating and removing plugins within my CakePHP applications. May be it could be even something visual? May be it could even fetch a feed from http://plugins.cakephp.org/

You could may be chose from different "channels" as "cakephp-essentials", "hot" (by download trend or something), "editor's choice", "developer tools" or just by (veryfied) stability like mature/stable, development, unstable etc.

It could work like:
1. Download newest CakePHP composer.json or zip.
2. Install it and create a new app within
3. Open Plugin Shell (console or graphical)
4. Choose the plugins I like and need for my current project and get them setup with their default settings
5. Let's bake a cake!

That said I think having two options to download CakePHP would simplify management:
1. composer.json which gets you the same as point 2
2. all in one zip file as we know it today

Because the more options you give, the more options you have to care/manage and take into consideration when it comes to things like reported issues. Do you want to ask "what package did you download?"?

I also wouldn't provide an option without core tests because it's good for devs to have them around, verify that their core still work according to the tests. If they don't want/need it, they still can delete it. May be offer a script for doing that in Console/cake?

Greetings from Switzerland
Marc

[mark_story]

I think the framework should come with its tests. 

Just so I understand the scope of what we're talking about, this builder would be some sort of web-ui that generates a composer.json and dumps it into the app skeleton? Or does it download the various zip files, open them and makes a new zip file of everything together?

-Mark

[Ravage84]

It could potentially be both. It would even just offer a tailored composer.json that reflects the choices.
But in hinsight of performance I would suggest that, also like I understood Jose, a script prepares every potential combination after there is a new release.
With that way we certainly couldn't offer an unlimited number of choices because that would lead to potentially unlimited combinations. An ugly thing.

But the choice between a) a zip and b) just a tailored composer.json as a result of some few choices (core, debug_kit, some other must haves) was a good thing.
Even though I wouldn't include too many choices. People aren't good at choices, just remember that!

[Jose Diaz-Gonzalez]

My idea was two fold:

- Provide an interface for customizing the base install. This interface would allow you to choose any of the composer bits (cake core, external deps) as well as any of the core plugins, and then either spit out a zip file or composer.json. Both would be pre-generated and stored on server, as part of the release process. This solves our packaging issues in 3.x if we wanted to separate things, composer style, as well as allowing users to download official plugins off the bat. The zip would contain the appropriate composer.json file.

- Optional interface to create a composer.json based on any of the 3.x plugins on plugins site. I can update that code to detect composer.json files (it used to do that in an old version on my site) and then expose this info through some autocomplete api. This would be like a composer bootstrap. Lots of options to explore here, but that is the basic plan.

At no point would the second option result in a zip download with code. Only official stuff would be downloaded/packaged, and everything else would use composer.

I'd rather not build yet another tool people run locally to simulate composer. Composer is what I wanted 2 years ago, and I think we should embrace it.

As far as debugging issues, as long as we assume a certain core, we dont need to worry about that. If someone tries to run migrations but doesnt have it downloaded, thats pretty trivial to detect. I'm not saying split up the core, but rather just allow people to package some plugins we prefer people use. Lots of people don't know about debug_kit, or migrations. This is a solid way to promote use of things such as that.

As far as splitting out core tests, thats something Andy suggested (sorry andy!) but I don't care. Just an example.

Jose (little)

--

[Ravage84]

With external deps you (currently) mean PHPUnit and Composer, right? Somehow I still feel we aren't responsible for resolving these system depenencies.
They are system related and should be a responsibility of the person who is responsible for the system.
Relying on such a system dependency is OK. Documenting that in the installation process is easy.

Requirements:
- Composer, don't have it? Go get it and install it! ;-)

And even though I like the idea of customizing my CakePHP download I think there are some distinct differences between CakePHP and Twitter Bootstrap or Jquery UI.
Even though both can be considered as "frameworks" they are a different kind of framework. First of all they are no backend but a frontend/UI framework.
Both of them are just (an important) part of your application but not the core of your or even your application.
The reason why you can customize your download for them is a different than we have.
Where size for CSS & JS can matter it normally does not for backend stuff.
When you don't need a Twitter Bootstrap component, you can exclude it from the resulting file which will result in less traffic on your site.
But if you don't use a component/plugin or whatever for CakePHP, it doesn't matter (much) if you have it installed or not.

And yes buliding another PEAR or Composer was stupid!
But a shell that enables the user to add or to remove plugins from their composer.json file could fill that gap between our CakePHP plugin landscape and the functionality that composer gives us by default.
Where plugins.cakephp.org could be something like our own packagist.org.
Updating the plugins is a chore that can be done through composer itself.

If you want to promote some must have plugins, you could do that on the home.ctp (and/or the cookbook) by giving the user a copy & pastable plugin shell command.
This could look like:

Console\cake plugins add cakephp/debug_kit stable

You can add or remove a plugin (debug_kit) from an maintainer (cakephp) using a certain stability (stable) or may be a branch (would be "master").

- Right now I believe the best solution would be offering two files:
1. a zip file with everything you need (core, with/without app, tests)
2. a composer.json to get the same as point 1
- Keep out the system deps.
- Give the user a shell (console and/or web based) with which they can add or remove plugins.

[Jose Diaz-Gonzalez]

Response inline.

On Fri, Aug 2, 2013 at 11:49 AM, Ravage84 <ravag...@gmail.com> wrote:

With external deps you (currently) mean PHPUnit and Composer, right? Somehow I still feel we aren't responsible for resolving these system depenencies. 

They are system related and should be a responsibility of the person who is responsible for the system.
Relying on such a system dependency is OK. Documenting that in the installation process is easy.

Yes, I mean adding `phpunit` to your composer.json if necessary. I do not mean bundling composer with the cakephp install.

 

Requirements:
- Composer, don't have it? Go get it and install it! ;-)

And even though I like the idea of customizing my CakePHP download I think there are some distinct differences between CakePHP and Twitter Bootstrap or Jquery UI.

I am thinking only things we host on the CakePHP plugins site. Not some random other nonsense. If there ends up being a package that depends on TB or jQuery, then running composer locally will resolve that dependency. CakePHP official zips will likely not have this issue.

 

 

Even though both can be considered as "frameworks" they are a different kind of framework. First of all they are no backend but a frontend/UI framework.
Both of them are just (an important) part of your application but not the core of your or even your application.
The reason why you can customize your download for them is a different than we have.
Where size for CSS & JS can matter it normally does not for backend stuff.
When you don't need a Twitter Bootstrap component, you can exclude it from the resulting file which will result in less traffic on your site.
But if you don't use a component/plugin or whatever for CakePHP, it doesn't matter (much) if you have it installed or not.

And yes buliding another PEAR or Composer was stupid!
But a shell that enables the user to add or to remove plugins from their composer.json file could fill that gap between our CakePHP plugin landscape and the functionality that composer gives us by default.
Where plugins.cakephp.org could be something like our own packagist.org.

That is planned.

 

Updating the plugins is a chore that can be done through composer itself.

Adding a single line to a json file is not a chore. Parsing json, while trivial, is not something we should do, since it just adds complexity.

 

If you want to promote some must have plugins, you could do that on the home.ctp (and/or the cookbook) by giving the user a copy & pastable plugin shell command.

Would be nice to have documentation on adding a package to your composer file. I agree. Very easy to do.

 

This could look like:

Console\cake plugins add cakephp/debug_kit stable

You can add or remove a plugin (debug_kit) from an maintainer (cakephp) using a certain stability (stable) or may be a branch (would be "master").

- Right now I believe the best solution would be offering two files:
1. a zip file with everything you need (core, with/without app, tests)

No. My point is to allow people to download all in one packages. The above zip would be the base installation, and would be the one we promote over all others. But it would be one of many options.

 

2. a composer.json to get the same as point 1 

Sure.

 

- Keep out the system deps.

Eh, whatever.

 

- Give the user a shell (console and/or web based) with which they can add or remove plugins. 

No, thats just adding more code that no one will maintain. Cake 3.0 already has a bunch of cruft no one maintains/updates - woot bake! - and I think we should strive to remove complexity, not add another piece that would lead to people using it wrong.

If you can't use json, maybe you shouldn't be using composer. I feel as though this is more of an education issue than anything else.

[Ravage84]

See inline.

Am Freitag, 2. August 2013 17:56:00 UTC+2 schrieb Jose Diaz-Gonzalez:

Response inline.

On Fri, Aug 2, 2013 at 11:49 AM, Ravage84 <ravag...@gmail.com> wrote:

With external deps you (currently) mean PHPUnit and Composer, right? Somehow I still feel we aren't responsible for resolving these system depenencies. 

They are system related and should be a responsibility of the person who is responsible for the system.
Relying on such a system dependency is OK. Documenting that in the installation process is easy.

Yes, I mean adding `phpunit` to your composer.json if necessary. I do not mean bundling composer with the cakephp install.

OK, just thoght we were talking about composer, too, because Ceeram suggested that here.

 

Requirements:
- Composer, don't have it? Go get it and install it! ;-)

And even though I like the idea of customizing my CakePHP download I think there are some distinct differences between CakePHP and Twitter Bootstrap or Jquery UI.

I am thinking only things we host on the CakePHP plugins site. Not some random other nonsense. If there ends up being a package that depends on TB or jQuery, then running composer locally will resolve that dependency. CakePHP official zips will likely not have this issue.

I just wanted to show that there are different reasons why those two have a customizable download page...
 

 

 

Even though both can be considered as "frameworks" they are a different kind of framework. First of all they are no backend but a frontend/UI framework.
Both of them are just (an important) part of your application but not the core of your or even your application.
The reason why you can customize your download for them is a different than we have.
Where size for CSS & JS can matter it normally does not for backend stuff.
When you don't need a Twitter Bootstrap component, you can exclude it from the resulting file which will result in less traffic on your site.
But if you don't use a component/plugin or whatever for CakePHP, it doesn't matter (much) if you have it installed or not.

And yes buliding another PEAR or Composer was stupid!
But a shell that enables the user to add or to remove plugins from their composer.json file could fill that gap between our CakePHP plugin landscape and the functionality that composer gives us by default.
Where plugins.cakephp.org could be something like our own packagist.org.

That is planned.

 

Updating the plugins is a chore that can be done through composer itself.

Adding a single line to a json file is not a chore. Parsing json, while trivial, is not something we should do, since it just adds complexity.

I wasn't talking about adding/removing a single line to the composer.json here. But actually updating dependencies (e.g. a chosen plugin) defined in the composer file... Never mind...
 

 

If you want to promote some must have plugins, you could do that on the home.ctp (and/or the cookbook) by giving the user a copy & pastable plugin shell command.

Would be nice to have documentation on adding a package to your composer file. I agree. Very easy to do.

 

This could look like:

Console\cake plugins add cakephp/debug_kit stable

You can add or remove a plugin (debug_kit) from an maintainer (cakephp) using a certain stability (stable) or may be a branch (would be "master").

- Right now I believe the best solution would be offering two files:
1. a zip file with everything you need (core, with/without app, tests)

No. My point is to allow people to download all in one packages. The above zip would be the base installation, and would be the one we promote over all others. But it would be one of many options.

I understood that, but like I said I don't feel we need that cusomizable dowloads.
Give the people a base install (or the composer.json for the same) and by promote the plugins on plugins.cakephp.org.

 

2. a composer.json to get the same as point 1 

Sure.

 

- Keep out the system deps.

Eh, whatever.

Sorry, the external deps we were talking earlier ;-)
 

 

- Give the user a shell (console and/or web based) with which they can add or remove plugins. 

No, thats just adding more code that no one will maintain. Cake 3.0 already has a bunch of cruft no one maintains/updates - woot bake! - and I think we should strive to remove complexity, not add another piece that would lead to people using it wrong.

If you can't use json, maybe you shouldn't be using composer. I feel as though this is more of an education issue than anything else.

OK, agree. Forget about that additional shell. Probably "Featuritis" got me for a second ;-)
It's true adding that single line to "require" in your composer.json is easy and we don't add additional complexity to CakePHP.

So we could add on each plugin page a generated short installation doc how to include it into your composer.json.
For http://plugins.cakephp.org/p/52-debug_kit e.g. could that be:

"For adding this plugin to your application, add the following line under "require" to your composer.json in your applicaion's root folder:"
 

> "cakephp/debug_kit": "2.2.*"

"Run 'composer install' after that. See the official Composer documentation for more information"

Again, even though the idea of customizable downloads is nice, I don't think we need it.
Give the user a base installation package (or the json alternative) but let's improve plugins.cakephp.org so it becomes the real one stop for getting information about CakePHP plugins and installing them.

The biggest value of all cusomizable download solutions for me would be the one for creating a composer.json with your desired plugins.
So you download and install the base installation zip.
Go to the custom composer.json script page.
Chose the plugins you want.
Let it generate.
Copy & paste that into the existing composer.json of the base installation zip.
Execute a 'composer install'.

Et voila you have your ready to go CakePHP installation.
Alternativly you don't need to download the base installation zip, because the custom generated composer.json could include that, too...

[Ravage84]

So we could add on each plugin page a generated short installation doc how to include it into your composer.json.
For http://plugins.cakephp.org/p/52-debug_kit e.g. could that be:

"For adding this plugin to your application, add the following line under "require" to your composer.json in your applicaion's root folder:"
 

> "cakephp/debug_kit": "2.2.*"

"Run 'composer install' after that. See the official Composer documentation for more information"

RTFM to myself ;-)

php composer.phar require vendor/package:2.*

will suffice...

I assume plugins.cakephp.org could provide a periodically generated satis because I don't think we need a Symfony2 based Packagist application for the existing plugins page.
And if we add the plugins page as a repository to CakePHP's composer.json, people could search for packages (plugins) from their console.