Will Yii 2 utilize composer packages?
Will Yii 2 utilize composer packages?
Yes was about extensions. Yii2 itself divided to independent packages, not likely.
Will you force developers to include a composer.json file to get his package listed at yiiframework?
I would suggest it, as packagist does.
What’s about splitting up Yii like symfony? see https://github.com/symfony/symfony-standard
E.g. the zii widgets could be a separate package.
Another thing to think about is, how Yii handles dependencies to libs like jquery. I often had conflicting versions with Yii, jQuery and jQuery Plugins.
Yes, we will.
Zii most probably will be a separate package.
@samdark: Here’s an interesting posting from a Joomla-Dev about splitting up the core into composer packages and interface handling.
Btw: For extensions I’d recommend a composer package type ‘yii-extension’ and ‘yii2-extension’ respectively. There may also be packages with the types ‘yii-theme’ and ‘yii-application’.
@samdark, @qiang: What’s the status of composer integration in Yii 2? Like application bootstrapping and extension conventions (namespaces, etc…), or an extension repository.
I talked to several Yii users/devs in the past weeks and we’d like to know about the implementation plans, so we can port as much of them back into Yii 1.x
For sure I’d also have tons of input for you about this topic.
Looking forward to hear from you,
The focus now is on the core itself. I think composer will be probably handled after alpha.
Have you already made a decision about using packagist.org or an own repo?
No. Any advices?
Will yii-extensions have their own package type, or will they just work out of vendor. Makes no difference to the user (packages are required as usual), but would seperate yii-specifics from general purpose packages.
FYI: Their is allready an install-type for yii-1.1 extensions and modules:
I haven’t considered this option. Can you explain how it works?
well done !
I hope with different names, like “jQuery UI package” etc.
for the “tl;dr” - guys, just read the bold parts
I am very glad Suralc raised the composer installer topic.
Thanks to his posting I just noticed, that there is an Yii installer already.
But the current implmentation of the Yii installer is pretty useless, it is doing things wrong and raising problems, IMHO.
To be honest, I haven’t tried it out, but it is pretty obvious what it does.
The installer would put a package of the type "yii-extension" into protected/extensions and one of the type "yii-module" into protected/modules, when you run composer update or install.
First, if your application has a different directory structure than a standard Yii Web Application Skeleton it will fail, because the destination directories are missing. Moreover it is just using the package name without the vendor name, which may lead to additional conflicts.
Second, even if you have the directories mentioned above, you’ll still have issues versioning your project, because you may mix up your own code, like in modules, with code, which is managed by composer.
Usually, you just commit composer.lock for the code you get from composer, because if you run composer install you’ll get the exact revisions, which have been written to this file, see this link for more info.
Luckily, as layed out in this wiki article, you don’t need to place your extensions and modules in the directories mentioned above, even for Yii 1.1.
An exception are themes, because this is code you’ll very likely going to modify and an installer may be useful here. But developers have to require the installer in their theme package and moreover the installer also has to be able to find out your theme directory.
The installer directories should not be hardcoded, because we would loose the ability to define custom dir-structures for our projects.
Because of all the points now mentioned I sticked with composer script events, for Phundament, which are way more flexbile than installers.
As an example, it’s very easy to run migrations or setup directory permissions when installing an extension or copying theme files into the right place, just by executing yiic commands.
There may be a way to enhance the installers, but I found it more complicated than using the script events - Let me know if someone has ideas how to accomplish this.
[b]So here’s my summary for the installers:
Yii2 should use the vendor/ folder for project extensions, custom modules may go into modules/ and extensions not available via composer go into extensions/
Yii2 should introduce these composer types "yii2-extension", "yii2-theme" and "yii2-application" (similar to the web app skeleton) - which would be important for searching through a large number of packages and also using installers later on.
I think this is the right time to link to some “Yii Application Standard Request” docs we’ve creeated, which treat the same subject, please note that they are just proposals! And we’d be very happy about feedback.
So now on to the question where to host the package information.
You’ve basically two options:
the main composer repository, existing packages are there already
easy to use, repo is preconfigured in composer.phar
available as Open Source from https://github.com/composer/packagist (but it’s a Symfony project )
a bit slow, due to the large number of packages
you’re relying on infrastructure from someone else
policy could be to only allow Yii extensions and , which would be faster and cleaner
may be a Yii project
you’re relying on your infrastructure
you’ll have to build a web frontend on your own
users would have to include that repo in composer.json
a package may be registered at packagist.org and packages.yiiframework.com
[b]But as a summary for the hosting topic:
I’d use packagist.org.
Not mine. I was just lurking through the composer documentation. My projects usually have no protected dir placed in the webroot.
However, yii should support variable structures. And I’m not yet convinced that composer can handle packages distributed to several places inside an app with the current flexibility of yii.
Wow. Thanks for your input. Really useful.