RE: [PHP-DEV] Package extension proposal
AM 2.) the PEAR-Installer create a package file of the 'your' AM format from the XML package file maybe would be better. Let's see what other people think. I forgot a possiblity, one task of the installer should be to store data of the installed pear-packages in flat-file database. This is'nt implemented yet, but it maybe a starting point for a good solution. There's always a serialised php data structure. Would be faster I imagine than parsing a flatfile. -- Richard Heyes -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Package extension proposal
I definitely agree that this would be a cool thing to have. Today PEAR packages do all of this with PHP code, a more tightly integrated package concept would be very nice. Comments below. Stanislav Malyshev wrote: Below is the proposal for PHP packaging extension. The intentions is for PHP to have the package system kind of like what Perl and other languanges have. The comments and suggestions are most welcome, as usual. Especially the experience with packaging system from other languages. === Name: Package Extensions Draft Version: 1.0 Author: Stanisval Malyshev [EMAIL PROTECTED] Goal: Create a system that will allow to create and conveniently handle PHP code bundles, containing one or more PHP code files bound by the common function. Requirements: The system should: * allow convenient loading of the whole package with the single statement * allow convenient checking if the package is loaded * allow the user to conveniently pack the package and to describe relationships between the packages * this is not meant to replace include() and include_once() but to add functionality that will allow more systematic view on the PHP code tree * the system should sit well with future namespace implementation, allowing packages to use the benefits of the namespaces The system is meant to be implemented as a PHP extension. On the best of my knowledge, it can be implemented without interfering with any existing code and without needing any code modification in any other parts of PHP/Zend. Proposed functions: === package_load(Name) Loads the package with name Name. The loading is done in the global scope (as opposed to include()). Returns true on success. If the package with this name was loaded, it just returns true, while doing nothing. If the package cannot be found, it returns error. TBD: fatal error or not? Since it just returns if the package is already loaded, I think package_use() or use_package() would be better names for this one. To me, load is unconditional. package_is_loaded(Name) - Returns true if the package is loaded, false otherwise. package_set_path(path) Sets the package path for looking for packages. The default is the include path. Yes! This function could be a real problem-solver for those with less-than-helpful ISPs. Technology: == Package is located and loaded in the following way: 1. First, the package location name is determined. If the name does not contain :: signs, the package location name is the package name. If the package name contains ::, each :: component is a subdirectory, i.e. Foo::Bar::Baz produces the location name of Foo/Bar/Baz (just like in Perl). 2. Package location name is prepended with each directory in the package path. The '.pdef' extension is added to the path. If a file with such name exists, this is a package definition file, which is parsed according to 3. If not, the '.php' extension is added to the above path. If a file with such name exists, it is considered to be the main file of the package and is included with global scope. This file should require_once the rest of the files. 3. The package definition file has format like the following: Package: Foo::Bar Version: 3.14.15 Requires: PEAR Requires: DB::MySQL Files: boobar.php boo.inc classes/class.A.inc classes/class.B.inc Package: line defines the name of the package, should be the same as is required (as a sanity control measure). Version: is not used in the meantime. Requires: line defines that this package depends on other package, which should be loaded before this package is loaded. This line can be repeated a number of times. Files: line marks the start of the file list. The next lines of the file, until the end, will be package filenames, one per line. The pacthes are relative to the package directory. The files are included (just like include()) in the global context and executed, one by one. It is not recommended to put any global-scope code but definitions and variable definitions into these files. I think packages should be able to contain both PHP code files and extension libraries. This would save coders a lot of hassle, and would be a great feature to have when extensions start moving from php4 to pear/PECL. It would be interesting to compare the performance of an XML-based package definition file and a plain-text one. If the overhead is acceptable I think we should go with PEAR's package XML format. If the overhead is too big I think your format is fine. My suggestion is putting this thing in php4/ext/pear. I want to move some other code there too, but this would be a good start. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list
Re: [PHP-DEV] Package extension proposal
PEAR has already a XML-based package file format, which is already used for installation and information retrieving. Is it documented somewhere? Also, I fear that XML would be too slow for time-critical operation like including files on runtime, but I might be mistaken. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Package extension proposal
Is it documented somewhere? The DTD is in php4/pear/package.dtd Also, I fear that XML would be too slow for time-critical operation like including files on runtime, but I might be mistaken. Could be possible. Solutions: 1.) creating a c-function, which parses the xml-file 2.) the PEAR-Installer create a package file of the 'your' format from the XML package file -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Package extension proposal
AM Also, I fear that XML would be too slow for time-critical operation like AM including files on runtime, but I might be mistaken. AM Could be possible. AM Solutions: AM 1.) creating a c-function, which parses the xml-file The problem is that I do not want to create dependency on any XML parser extension, and I do not want to rewrite the parser also. So I guess that this: AM 2.) the PEAR-Installer create a package file of the 'your' AM format from the XML package file maybe would be better. Let's see what other people think. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Package extension proposal
AM 2.) the PEAR-Installer create a package file of the 'your' AM format from the XML package file maybe would be better. Let's see what other people think. I forgot a possiblity, one task of the installer should be to store data of the installed pear-packages in flat-file database. This is'nt implemented yet, but it maybe a starting point for a good solution. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Package extension proposal
Below is the proposal for PHP packaging extension. The intentions is for PHP to have the package system kind of like what Perl and other languanges have. The comments and suggestions are most welcome, as usual. Especially the experience with packaging system from other languages. === Name: Package Extensions Draft Version: 1.0 Author: Stanisval Malyshev [EMAIL PROTECTED] Goal: Create a system that will allow to create and conveniently handle PHP code bundles, containing one or more PHP code files bound by the common function. Requirements: The system should: * allow convenient loading of the whole package with the single statement * allow convenient checking if the package is loaded * allow the user to conveniently pack the package and to describe relationships between the packages * this is not meant to replace include() and include_once() but to add functionality that will allow more systematic view on the PHP code tree * the system should sit well with future namespace implementation, allowing packages to use the benefits of the namespaces The system is meant to be implemented as a PHP extension. On the best of my knowledge, it can be implemented without interfering with any existing code and without needing any code modification in any other parts of PHP/Zend. Proposed functions: === package_load(Name) Loads the package with name Name. The loading is done in the global scope (as opposed to include()). Returns true on success. If the package with this name was loaded, it just returns true, while doing nothing. If the package cannot be found, it returns error. TBD: fatal error or not? package_is_loaded(Name) - Returns true if the package is loaded, false otherwise. package_set_path(path) Sets the package path for looking for packages. The default is the include path. Technology: == Package is located and loaded in the following way: 1. First, the package location name is determined. If the name does not contain :: signs, the package location name is the package name. If the package name contains ::, each :: component is a subdirectory, i.e. Foo::Bar::Baz produces the location name of Foo/Bar/Baz (just like in Perl). 2. Package location name is prepended with each directory in the package path. The '.pdef' extension is added to the path. If a file with such name exists, this is a package definition file, which is parsed according to 3. If not, the '.php' extension is added to the above path. If a file with such name exists, it is considered to be the main file of the package and is included with global scope. This file should require_once the rest of the files. 3. The package definition file has format like the following: Package: Foo::Bar Version: 3.14.15 Requires: PEAR Requires: DB::MySQL Files: boobar.php boo.inc classes/class.A.inc classes/class.B.inc Package: line defines the name of the package, should be the same as is required (as a sanity control measure). Version: is not used in the meantime. Requires: line defines that this package depends on other package, which should be loaded before this package is loaded. This line can be repeated a number of times. Files: line marks the start of the file list. The next lines of the file, until the end, will be package filenames, one per line. The pacthes are relative to the package directory. The files are included (just like include()) in the global context and executed, one by one. It is not recommended to put any global-scope code but definitions and variable definitions into these files. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Package extension proposal
package_load(Name) package_is_loaded(Name) package_set_path(path) +1 3. The package definition file has format like the following: PEAR has already a XML-based package file format, which is already used for installation and information retrieving. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]