Posted 23 January 2013 - 05:17 PM
Posted 28 January 2013 - 06:46 AM
I would suggest it, as packagist does.
What's about splitting up Yii like symfony? see https://github.com/s...ymfony-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.
Posted 29 January 2013 - 04:28 AM
Zii most probably will be a separate package.
Posted 10 March 2013 - 10:40 AM
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'.
Posted 13 March 2013 - 12:38 PM
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,
Posted 13 March 2013 - 12:56 PM
Posted 29 March 2013 - 01:14 PM
Posted 29 March 2013 - 04:51 PM
FYI: Their is allready an install-type for yii-1.1 extensions and modules:
Posted 29 March 2013 - 05:43 PM
Posted 30 March 2013 - 09:02 AM
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.
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
2. Do it on your own with Yii and satis
+ 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
But as a summary for the hosting topic:
I'd use packagist.org.
Posted 30 March 2013 - 11:53 AM
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.
Posted 30 March 2013 - 04:41 PM