Re: [PHP-DEV] Package extension proposal

[Stig S. Bakken]

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 
To uns

RE: [PHP-DEV] Package extension proposal

[Richard Heyes]

> > 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 
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

[Alexander Merz]

> 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 
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

[Stanislav Malyshev]

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 
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

[Alexander Merz]

> 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 
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

[Stanislav Malyshev]

>> 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 
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

[Alexander Merz]

> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]