[dev] Fwd: [PEAR-DEV] going away present

[Jan Schneider]

Just FYI.

----- Weitergeleitete Nachricht von cellog at php.net -----
    Datum: Sat, 02 Oct 2004 02:08:49 -0400
    Von: Greg Beaver <cellog at php.net>
Antwort an: Greg Beaver <cellog at php.net>
 Betreff: [PEAR-DEV] going away present
      An: pear-dev at lists.php.net

Hi all,

I'm on my way out the front door to a vacation in Paris on Sunday, but
as a going-away present to you, the PEAR developers, I thought you might
like to know that progress towards completion of package.xml
implementation has been moving along at a good clip.

First things first, custom file roles can be added to the installer now.
  I have not yet had the time to brain my way around all of the ways
this could be abused, so don't consider the implementation to be final
by any stretch.  A custom file role can also add configuration variables.

This will allow, for instance, an app to add a custom role for files
that contain database definitions that are modular in some way, so that
future upgrades can automatically update things.  Other examples include
defining some kind of htdoc role like what was toyed with earlier in the
year.  The main point is that none of these roles will be required, and
the default roles still work just great as they always have.  Also, none
of this applies to package.xml 1.0 - this format is set in stone.  Only
package.xml 2.0 releases can use new custom file roles.

In addition, an application CANNOT define a role in its own package.xml
and then use it.  The role must have already been installed by a
separate package, meaning users can't inadvertantly install a new role
by installing "DB", unless DB contains a role that it doesn't use.
There will probably have to be a strict check on files to see if they
install into the PEAR/Installer/Roles directory, and if they do, perhaps
installation could automatically fail without an explicit command-line
switch.  This way, users can't even accidentally install a role they
don't want to.  More thought needs to be done along these lines.

I've also added but not yet implemented the exciting new "package" role,
which allows a .tgz to be directly bundled, and installed along with a
package.  It makes installing without internet very straightforward.

Second things second, I've expanded the age-old <replace> tag to be a
whole subset of tags called "tasks" a-la-Phing.  These are not as
versatile as Phing tasks, in the name of keeping things both simple and
secure.  However, the implementation makes doing both pre- and
post-installation scripts a piece of cake.  This implementation is far
more strict than file roles, and literally prys open the files to
validate the name of the single class it's allowed to contain and its
methods.

<file name="scripts/install.php" role="script">
  <tasks:postinstallscript/>
</file>

this causes an error - only php roles can be post/preinstallscript

<file name="scripts/install.php" role="php">
  <tasks:postinstallscript/>
</file>

here, the installer will pry open scripts/install.php and look for a
class named "scripts_install_postinstall" with methods "init" and "run".
  It doesn't verify method signatures, but these reasonable checks
should strike out most unintentional install scripts.  init is passed a
PEAR_Config and a PEAR_Frontend_* object.  All output for the user
should be done using the PEAR_Frontend_CLI/Web/Gtk object to allow easy
use for all.

Even better, the postinstallscript task can use the package that was
just installed!  An added bonus that occurs because of the way tasks
work is that you can do this:

<file name="scripts/install.php" role="php">
  <tasks:replace from="@version@" to="version" type="package-info"/>
  <tasks:replace from="@data_dir@" to="data_dir" type="pear-config"/>
  <tasks:postinstallscript/>
</file>

and the replacements will take effect before the script is called.  Tag
ordering is important.

My thought is that a postinstallscript can be used in a package that
distributes a custom file role to set up the configuration variables it
creates, or for more obvious things like database creation, etc.  The
PEAR_Server package will be using this to help configure the channel
database.

So, that's the present.  Application support becomes near to a complete
reality with all of these features.

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



----- Ende der weitergeleiteten Nachricht -----


Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/