Phar support distribution

Hi folks… I have an idea…

Can be posible distribute the framework on a phar file??

I think with the framework outside of application, if the app have a structure like the actual structure, then I think in the index.php file of the app like this:


<?php


// change the following paths if necessary

$yii=dirname(__FILE__).'/../../YiiFramework/yii.phar';//The framework PHAR

$config=dirname(__FILE__).'/protected/config/main.php';//The app config file


// more code...


require_once($yii);

Yii::createWebApplication($config)->run();



Same idea for extentions and modules.

What did you think??

I’ve been wanting this for a while, and today I made it work.

I wrote this script which you can use to package the framework to a single file.

Follow the instructions at the top of the file.

Note that CAssetManager was designed with the assumption that paths map to physical files, and therefore did not work when the Yii framework path is set to a phar:// stream-wrapper path.

I submitted the following patch, which you will need to apply for this to work:

http://code.google.com/p/yii/issues/detail?id=3104

Sounds cool, what’s the file size of the framework as phar?

I like your thinking.

What about Modules and Applications as phar? Seems like CModule has to be patched, too.

Are there any performance tests phar vs php files?

drx

About performance: php-dev list (notice that the post is from 2008).

Around 6 MB.

I have no particular interest in this myself.

I mainly want it like this for version-control purposes - checking in 1700 files was a chore, upgrading the framework was a monstrous and messy operation.

I am quite comfortable checking in third-party modules - in fact, I prefer to do so, since third-party modules frequently need a patch or modification. The framework has proven very reliable, stable and backwards-compatible, but third-party modules have a fraction of the userbase of the framework itself, and can’t be “trusted” to the same degree, in my opinion. I don’t find it’s safe or practical to package them - in contrast to packaging the framework itself, which I find discourages “hacking” the Yii core.

thank you for the link. didn´t know that phar is that old.

sp - no performance issues when using phar files. what about using more than one phar file?

drx

You are right. This may take some time - even with git. Maintenance and deployment of applications will be much easier - or lets say faster - with yii as phar.

This also may apply to vendor libs, extensions and -ok major- modules. What i miss is some sort of standard packaging for especially yii extensions and modules. phar could be one vehicel for it - just think of http://packagist.org which seems to be build around Symfony 2 bundles and github mainly, but also could be used for yii libs.

Then again i really like plain PHP files to dig into the code and to have auto code completion in eclipse. PDT seems to kind of support PHAR files as Libs since PDT 2…

What about building and deploying a complete yii app as phar. Does this make any sense? Write protection?

Perhaps to very large modules, I mean maybe 300-500 files or larger. And only for something with a substantial userbase and trusted developers.

To be honest, I don’t know of any library for Yii that I would trust to that extend - I’m always finding errors in third-party libs, so for me, personally, if people started distributing lib/modules/extensions in phar format, that would just be a nuisance.

I prefer everything except the framework to be open and maintainable. If I have to correct something in the framework (which is rare) I consider it my duty to submit a patch; to me that’s a natural cycle of the open-source eco-system.

To me, absolutely not - totally unmaintainable :slight_smile:

Amaizing!! :rolleyes:

Like mindplay, I think it’s a better pattern a phar of the framework, but modules and extentions are more flexible in the traditional way.

Anyway, some libs or extension can be convert to phar, like swiftmailer, a templeate engine or another ORM, but that are concret case. For any else, get all the code and work it directly it’s a better choise.

Well… i has try to build my YiiFramework copy to phar, but I get this error:


PHP Fatal error:  Uncaught exception 'BadMethodCallException' with message 'unable to create temporary file'

Whats whrong??? :unsure:

You could be running into this bug - or perhaps you just need to check that PHP has write-permissions to the destination folder?

Quite nice, I’ve wondered about combining phar with Yii in the past, but as my experience with phar hasn’t gone past the reading of blog articles, I haven’t looked into it further.

Regarding the approach of using phar for modules or even an entire application, that seems like a good idea, but the runtime directory would have to exist outside of the phar at that point. Using a phar for an application or module that is receiving active development is of course pointless, but for deployment, or for situations where modules are developed for re-use across projects (and thus, all changes should ideally go back into the source repo), use and deployment of phar would be quite handy.

I try to develop my own code as standalone extensions, modules, widgets, etc, whenever possible, and it irks the hell out of me when junior developers or outsource developers then take a copy of the original code, make modifications, and then don’t track those modifications or submit changes back upstream, or even modify the code of an extension that is developed to be standalone and reusable, to add in application-specific logic… Modules, extensions, etc, should be viewed in the same way as the Yii framework itself should be viewed, and that is as a standalone component to which the source should not be modified. It can be extended, but not directly customized…

If I have time, I’ll start testing modules, extensions, etc, w/ phar. Just need to make sure there is a standard for versioning each item, similar to the binary package distribution systems used for Linux distros, and even support in the versioning for acknowledging fork/branch versions of a phar…

Awesome :slight_smile:

Agreed that most libraries in the Yii community seem to be undependable, but it’s slowly improving. If anything, there are certain developers that you can pretty consistently depend upon.

Ultimately, the phar concept would be best applied for a system that is built on top of Yii, like a CMS, as then the packaged phars would ideally have an approval process involved…