Background

As I'm been learning more and more about the "new" Zen of Zope app development, I've been relying more and more on building ZClassed based objects with PythonMethods and DTML Methods to encapsulate the functionality of my applications (rather than writing out straight Python code). My approach has generally been to rely on Python code only when I can't do it (or do it cleanly) thru a combination of ZClasses, DTML and PythonMethods...

This has made the code-test-debug cycle much faster (since I normally don't have to restart Zope that much anymore (which I have to whenever I update the python code)

As I continue to do this however, I am stymied by the complicated process whenever I try to distribute/deploy the applications I've made (compared to the two-step, simple unzip-into-the-products-directory- and-restart-zope installation with "traditional" Zope Products)

As an example, when I deploy my apps, I create a traditional "Zope product" for the python-coded ZClass base and other Zope products I use ; a .zexp file for every ZClass included in the app, plus another .zexp file for the instance data that might be used to set up the default data...

Then to deploy this, I take several steps : for the "traditional" Zope products its the same; then, for each ZClass .zexp file I go to the Products directory and import the file there (making sure of course that any python-based Zope product on which the ZClass is based on exists on the new Zope installation, of course); then going to the folder where I'm creating the application and finally importing the .zexp file which contains the instance data....

The Proposal

My proposal is to create a ZopePackManager Zope Product to automate this process. A ZopePack is defined as: A combination of one or more ZClasses, Extension Methods, plus instance data (all in .zexp format) that comprise a useful application.

In addition, a "meta-file" containing the some info about the ZopePack is created and provides a way for the ZopePackManager to query the ZopePack prior to installing it. Data included in the "meta-file" could include:

1. Textual descriptions about the application, for example:

• description/summary
• product category
• installation notes
• author/credits/version
• misc. text data

1. ZClasses included -- this will be used in determining possible namespace/version conflicts...
2. Products/ZClass dependencies -- this will allow the ZopePack Manager to validate if the ZopePack can be created successfully.
3. Acquisition property dependencies -- if the instance data needs some properties, methods etc existing in its acquisition hierarchy, they also need to be specified so that the ZopePack manager can check (although as a rule, it would be bad design to have a ZopePack instance data dependent on acquiring some functionality it needs on its containers -- ZopePacks should generally be self-contained...)

In terms of the actual implementation, the ZopePackManager is not that hard to develop -- the core functionality to bring in ZClasses and instance data is just a call to manage_importfile. It would also have some functions to read in and parse the "meta-file" (maybe an XML document?) and then use the data it parsed to do some checking for possible conflicts and check dependencies (e.g. missing products, missing ZClasses, incorrect/incompatible versions)

Benefits

The ZopePack concept does not replace Zope Products. Instead, it augments it. It makes it easier for those developing with ZClasses to deploy their applications.

It also provides a standardized structure for storing ZClass and instance data when we wish to deploy them as applications...

The ZopePackManager also provides a safety check (by making sure the dependencies are satisfied before allowing the ZopePack to be instanstiated). It also provides an easier way of finding the available applications (by displaying the "meta-file" descriptions/categories in a standard/automated way)

Usage Scenarios

ZopePacking a ZClass-based application

1. Someone builds a new application with ZClasses and DTML methods, Images, etc. inside a folder... now that its complete, its ready to be distributed.
2. Each ZClass that is needed by the application is exported into a .zexp file (see note below, however)
3. The folder that implements the application also exported into another .zexp file
4. A "meta-file" is created containing information. In the future, it might be possible to create a utility that will help create this file automatically or, at least, assist the ZopePack builder in building a correct one.
5. the zexp files and the meta file are then moved into a "standardized" directory structure (much like all ZopeProducts are created inside the Products Directory (i.e. /lib/python/Products -- the idea is that ZopePacks are created inside a standard directory (e.g. /lib/python/Products/ZopePackManager/ZopePacks/
6. The entire zope pack is then tarred & zipped for distribution (much like a Zope Product)

Installing a ZopePack

1. First of all, you'd need to install the ZopePackManager product. It's installed in the same way as all ZopeProducts are.
2. Next, download the ZopePack you need. You might also need to download and install some ZopeProducts or some other ZopePacks it is dependent on dependent on (check the README or installation docs for the ZopePack or even the meta-file)
3. Restart your Zope installation
4. Create your Zope Application by instantiating a ZopePackManager instance -- it does not create a ZopePackManager instance -- instead in its constructor screen, it allows you to select a Zope Pack you need and instantiates that instead. The ZopePack Manager checks to see which Zope Products and ZClasses are needed -- checks to see if they exist, and if the ZClass does not exist but is included in a ZopePack, then it gets loaded into the Control_Panel/Products directory. Otherwise, if not all the dependencies are satisfied, it will return an error screen explaining why it failed and how to correct it. In other words, if you did not check if which Zope Products or Zope Packs your particular Zope Pack was dependent on, it will tell you the error at this point and also give some pointers as to what is missing and where to get them... (it might a good idea to have a central website where all ZopePacks could get registered so that this process is as easy as it could get)

Note that an application does not have to create a .zexp file for each ZClass it is using -- especially if it was using a ZClass that came from another Zope Pack or ZopeProduct and your application was just using it.

In which case, it is just noted in the "meta-file" that your application is dependent on a ZClass or a ZopeProduct and that such a ZClass came from another ZopePack or Zope Product. The ZopePack Manager will be the one to ensure that those products or packs are first installed before allowing the ZopePack to be instantiated.

Conclusion

Now the only question is who, when and how is it going to be implemented? I've started to lay the groundwork by writing out this proposal -- I'd like to get the Zope community's opinion and advice.

As a matter of practical application, I'm planning to use this framework to implement the next version of Squishdot. The benefit I am hoping for (aside from the benefits that come by making use of ZClasses and the ZCatalog) is that it will be easier to make other developers create different Squishdot variants (e.g., different look and feels as well as different sorts of functionalities) but will still be easy to install and configure.

This ZopePackManager product will hopefully be used not only by Squishdot but by all developers using ZClasses or those wishing to create different variants of their applications -- your opinions, advice and help are all welcome.