LAUPRETRE François (P) wrote: >> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] >> >> Actually, I would say it would be better to have some "minimized" >> version which is extract-only, has all the comments stripped, etc. >> for inclusion in the archives. > > There's a difference between phar and PHK here. PHK is not a > deployment tool. Because of the high-level features it provides at > runtime (as the autoloader, access protection, and others) and also > as a design choice, a PHK archive is distributed and runs as-is. If > you want a deployment tool, take phar or any other 'auto-extracting' > script available, but please don't use PHK for this.
Please STOP spreading misinformation. phar is *not* a deployment tool, even though it can be used this way. Both go-pear.phar and install-pear-nozlib.phar run full-fledged customized PEAR installer code, and use this to do complex tasks like extract internal .tar files and install them to disk. phar is no more a deployment tool than PHP itself is. There is absolutely nothing preventing the creation of a full run-out-of-the-box application, and I have created as demo proof-of-concept a full PEAR installer that can be used to manage a local PEAR repository without the need to install the PEAR Installer as well as a fully functioning phar containing phpMyAdmin. In neither case was anything deployed. Neither go-pear.phar or install-pear-nozlib.phar extract files from *within* the phar and put them on disk. They extract files from .tar archives contained within the phar archive. > Well, actually, it is possible to extract the files from an archive. > It is provided as a built-in utility feature, but just to view the > files, not to run them after extraction. > > I don't want PHK to be used as a deployment tool because one of its > main goals is to make sure that, once it is packaged and distributed, > your application/library will keep its integrity. The configuration > files are put outside of the archive and the archive is viewed as a > virtual read-only file tree. This is quite the same as a binary > executable file, even if we are in an interpreted world here. Would > you consider it serious if you had to recompile your httpd file, for > instance, after any configuration change ? No, you are used to have a > never-changing httpd and, somewhere else, your configuration files. > PHK tries to enforce the same philosophy. It is not just a sort of > PHP-oriented tar-like toolbox like phar, it tries to provide a > high-level service to package maintainers, allowing them to > distribute their applications in a cleaner way than what is possible > today. > > And I am currently going further this way as I am currently adding a > built-in feature to extract default configuration files from a > package at runtime. This way, the package designer will just have to > where the default conf lies in the virtual tree, and the user will > have a standard way to extract them on installation. > > Another example of this philosophy is the ability to digitally sign a > PHK package, as it is another way to get sure that the file won't be > modified after it is distributed by a trusted source. the phar extension fully supports signing using md5 and sha1, with plans for gpg signing in the near future. > We can argue endlessly on the case as, on one side, Greg and Marcus > seem to consider that these high-level features (which represent 90 % > of PHK) are just small easy-to-do additions to phar-like features, > and on the other side, I do consider that it makes a huge difference > for the typical phar/PHK user. Once again, if I had done PHK for my > exclusive use, I would have stopped at the same feature level as > phar. But I am not interested in a project where I limit the audience > to php-internals members :) It is just a choice. PHP_Archive/phar has limited its audience to all users of PHP, and rather than prescribing a rigid model that all phars must conform to, PHP_Archive/phar allows both simple and advanced usage. PHK expects all users to do things the same way. This is the difference. I am writing a proof-of-concept front controller and phar browser and will present evidence of my claim that this is a useful but not intrinsically required feature. I hate to lecture, but your consistently wild exaggerations require some debunking. First of all, every web app is different. Some require some kind of mod_rewrite, some expect to be able to access / and have all URLs hard-coded as such (for instance linking to '/config.php' expecting that this will work). Most of them use include_once with relative paths of some sort, although a few use dirname(__FILE__). phpMyAdmin is loaded with relative includes, which assume that "." will contain the files to be included. This means that the files put into the phar (or PHK) require manual modification of ALL includes, so that code like "include 'blah.php';" becomes "include 'phar://alias.phar/blah.php';" At the same time, some applications read their own code to detect custom commands or other things of this nature, using opendir(). All access to this kind of code needs to be modified to browse inside the phar (again made easier if dirname(__FILE__) is used). To expect that some kind of generic code will always work for every web app is midguided at best. By limiting PHK to this behavior, you are in fact limiting PHK to distributing a few applications. on the PEAR side, PHP_Archive does not build in a "phar for dummies" yet - but it does have all kinds of customization options, and they do work for most applications I have tried it on. Those applications that PHP_Archive do not work right away to phar up can still be pharred with a little bit of customization. PHP_Archive also provides a manager for debugging a phar archive that can detect corruption and do advanced high-level stuff. PHP_Archive is still considered to be alpha because the work to add in more high-level stuff has not yet been done, while I and Marcus have been concentrating on solidifying the file format in pecl/phar and stabilizing the code. pecl/phar, like PDO, does not attempt to prescribe an absolutist development model, but instead a minimal interface that can be built upon to do advanced work. I must insist that you take replies in this thread off of internals, the list is devoted to questions of C code. The choice of PHK vs. pecl/phar is a straw man: PHK will not be included in PHP core simply because it isn't C. If your goal is simply to spread misinformation about phar, then by all means, continue to reply. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
