3.0 - require composer?

[AD7six]

Should 3.0 require composer?

Mark and I discussed it in the recent past http://dev.cakephp.org/cakephp-dev/2013-07-14#MmN13y-XvRK6jHQDOwRnWnA

The main problem that this fixes is that it makes class loading consistent.

Allowing a composer-doesn't-exist fallback means the following

1. needing to keep a reference to the autoloader 
2. updating the autoloader in certain circumstnaces 
3. since the autoloader is one of two classes - they need the same api

I'm in favor or making composer a requirement, if it's not installed the fix for that is installing it :)

Thoughts?

AD

[Ravage84]

I'm with you, because I believe composer will become a (even more than already) standard.
Relying on it doesn't seem to be far fetched today already.
And certainly it's not a PITA to resolve that system dependency anyay.
Not even on Windows!


I agree working with bake templates is no joy.
Any solution is welcomed.

Using Twig for bake templates sounds not so bad to me.
But be sure you will get a hell a lot of requests to use it for the views by default then ;-)

Sure it has to be documented and people have to learn it.
But there is already a documentation (+ a community etc.) and not all CakePHP "users" have to learn it, only if they want to work on bake templates.

In any case I prefer Twig over Mustache or any other template engine like Smarty *horror*.
Also other solutions like using asp tags seem prone to break sooner or later or for some users respectively.

"Perhaps people just need to update their app's composer.json so the autoloader is correct."
If there was a way around that it would be more sexy.
Can you "include" the content of file in composer and using that content for additional dependencies?

My question though is would we want to have a dependency like Twig while you decided some time ago that you don't want to have Doctrine?
I probably compare here apples with pears since Doctrine was a replacement for something more integral as Twig was...

Ciao
Marc

[AD7six]

Sorry the bake discussion was intermingled with the composer chat - I sholdn't have linked (here) to the irc discussion at all. I've posted the Bake "question" seperately.

AD

[José Lorenzo]

I'm with only using composer if we can easily create a cakephp distributable package containing the new dependency.

--
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.
 
 

[Frank de Graaf (Phally)]

Is it really a requirement? You could still do things manually right? I'm fine with making it a requirement though. I don't feel we need to make a fallback, because making another composer sounds silly.

Op woensdag 24 juli 2013 15:13:26 UTC+2 schreef AD7six het volgende:

[Juan Basso]

I agree with Lorenzo. Cake always had a package that you unzip and it is working. It helps to attract new users.

[Ceeram]

+1 on composer only, as i said in other discussion about this topic, we can simply include a composer.phar which can self-update. i guess the only thing for us is to ensure when doing a new release we include an update to date version again. I guess phing can handle that for us.

2013/7/26 Frank de Graaf (Phally) <in...@frankdegraaf.net>

--

[Christian Winther]

Think we should go with Composer only, would be fairly trivial to setup a script to automatically run "composer install" & zip it down for you though, if we still want that option :)

The php community as a whole is moving in that direction, and think it would be silly of us to not follow troup on that

[mark_story]

It sounds like everyone is on board for requiring composer by default. It also sounds like we'll be including composer or an install script part of the app skeleton zip files to make getting started easier. If composer is the standard we are going to use how do plugins interact with that? I'm sure everyone has a few internal plugins they don't publish. Would these packages be added to the app's composer.json file so the correct autoload file is generated?

I think the plugin class's features for loading plugins start to become less useful in a composer based world as well. Its main purpose would be to facilitate route generation, asset dispatching and bootstrapping. App's feature set starts to become less relevant as well. App::build basically becomes useless in composer only world. I think these kind of changes are positive overall but will require re-educating developers.

-

[Christian Winther]

if people have private repos, chanches are that they add it to the their git repo directly, or use git submodule. Thats what ive been doing since i made the switch 3 months ago :)

--
You received this message because you are subscribed to a topic in the Google Groups "cakephp-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cakephp-core/vi6iFH7en3k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cakephp-core...@googlegroups.com.

[Jose Diaz-Gonzalez]

You can use your own satis installation. We should have recommendations on composer usage for various use-cases though.

--

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.

[mark_story]

That is true and there are ways to install plugins using git as well.  I'm going to put together a proposal for how everything could work in composer only land and then we can discuss and decide from there.

I'm excited to start requiring composer, as it makes CakePHP much simpler, consistent with other PHP projects and allows us to potentially leverage other projects like monolog to make our and our communities lives easier.

-Mark

[mark_story]

I put together some ideas in a wiki page https://github.com/markstory/cakephp/wiki/Require-composer. 

Does this seem reasonable to everyone? Is there anything I've missed or things that seem wrong?

-Mark

[Jose Diaz-Gonzalez]

I am assuming this removes App::uses?

What do we recommend people do to keep their versioning up to date? Should we say that users should commit the plugin code, or just use composer.json to keep up to date on the servers?

[mark_story]

Yes App::uses() has been gone in 3.x for quite some time now.  I think versioning depends on the installation method. Composer's json file allows you to lock revisions, as does using submodules.

-Mark

[Ravage84]

I'm fine with everything.

But personally I don't see that we need to include the composer.phar into the all in one package.
This can - and normally is - resolved system-wide.

If the dev wants/needs to have a separate composer for the project he still could do that with a single download...

Marc

[Ceeram]

People having systemwide composer installed, will not use the all in one package, they will composer create-project cakephp/app.

The all-in-one package is meant for users not using composer yet, allowing them to download cakephp and run it without requiring the command line. composer.phar is included for their convenience and is used to install evrything within the package.

2013/9/2 Ravage84 <ravag...@gmail.com>

[mark_story]

I've put up a new pull request https://github.com/cakephp/cakephp/pull/1606 that does many of the changes we've discussed.  A few things had to change/have been deferred.

* The current App/ could not be repository root because of how PSR-0 autoloaders work, the additional App/ directory is required. However this has allowed the project root to contain tmp, and webroot, keeping App/ for just code + templates which is a nice improvement.

* The changes for Plugin autoloading/namespacing have not been included as it would make the already large pull request even less manageable. I'll be doing a separate pull request for just the plugin changes.

I'd like to get any feedback you have about this. The new application structure and changes to the CakePHP repository create some big differences in how people will interact with the code and their applications so I'd like to make as few mistakes as possible :)

-Mark

On Wednesday, 24 July 2013 09:13:26 UTC-4, AD7six wrote:

[mark_story]

Thanks for all the great feedback on the pull request so far.  I've made a few more changes that if anyone thinks are crazy I'd like to know.

I've moved the Plugin directory out of the App/. This was done for a few reasons:

* It means we don't have to update composer/installers, which expects Plugin/ to be in the 'root' adjacent to vendor.

* Conceptually plugins are separate packages that are not part of the App\ namespace. Putting them under App implies the opposite of that.

I'd like to also make this a reminder to get your thoughts in on this change as I'd like to get it merged early next week. I'm currently waiting on these changes before I continue work on the Plugin and App classes which can shed a few more features with composer being added.

-Mark