I've used Features on one of my sites and think it is pretty good. However I was a bit concerned in that it relies on another module (?Context?) for something, and hence it cannot create a module from anything on your site, only the things this other module can see. In any case this is about Package Builder ...
First thing to notice is that its version is 1.0 alpha 2 right now. Obviously they don't mean for this to be installed on a production website. The project page also mentions a complete rewrite that's underway. These factoids don't make me terribly comfortable because obviously the module isn't ready for real use. However our project is aiming for four months in the future, so we may be lucky. Also they've taken the D7CX pledge so we may be doubly lucky.
Installation is easy, just drop it in sites/all/modules and enable it.
I was initially confused - the admin screen doesn't show anything about the module. Hence, how was I supposed to configure it or use it? In the module source there isn't even an _menu hook, so there's no way for there to be an admin screen. WTF?
Turns out that you're supposed to use 'Create Content / Package Builder'. I don't get why that's the case. Why would you create a node in order to create a Package? This doesn't make any sense. There are plenty of other modules that maintain lists of thingymajiggy's and do so without creating a 'node' of any kind. For example, Views, you don't create a Views node to create a View, do you? Ditto with Panels, Context, etc.
Since this is an administrative tool I believe it should have a link off the admin page. Clearly the author of this module have a different idea of what's what.
In the 'node' for each 'package' you have a bunch of collapsible fieldsets that control different aspects of the package being built. This includes
- Menu settings
- Inclusion of specific nodes
- "Vardumps" which, on my site, is empty but implies it will be a listing of specific variables.
- Specific Views
- Like "Vardumps", "Flags" and "Rules" are there and also empty... WTF? Oh, right, it's alpha2 so maybe this is unfinished stuff.
- Roles - I didn't export a role but I assume it will export the permissions for that role.
- Modules
- Inclusion of specific users
- Content type definitions
Unlike the Features module, Package Builder seems able to dump out anything into a package. You can dump the definition for any View, any content type, etc. Well, it doesn't have support to dump the configuration of a specific module. For example if you configure your SWF Tools module (and other media modules) just right, and then want to share that configuration with other sites, Package Builder doesn't at this time provide support. The project page discusses some hooks that modules can implement, so maybe that's a matter of other modules teams doing some work.
The generated module gets dropped into your files directory (sites/default/files/packages/...name...) and is itself a module.
Here's something that confuses me about both Package Builder and Features - why is the packaging format a module? Is this a matter of all we have is a hammer so everything looks like a nail? That is, the tool we have is the module so we have to squeeze these packages into being modules?
I am not groking why packages are modules. Why aren't they a 'package'? A package seems to be not about providing its own functionality but about packaging configuration of functionality provided by a set of modules. Hence it is different from a module.
Again, obviously the authors of these modules are obviously seeing it differently than I am.
The module created by Package Builder is rather interesting and in fact is a great demonstration of the point I just made. The .module file it generates is empty. It contains a .info file listing all the modules required by the package. It includes a .install file which contains _install and _uninstall methods. The meat of the package is subdirectories containing PHP scripts containing appropriate object definitions. For example the views directory contains PHP scripts which are the equivalent of views export, similarly the CCK directory contains PHP scripts which are the equivalent of cck export.
The _install method simply runs those scripts. The generated module is exactly that simple. It packages configuration in a format which fits with the module install and uninstall lifecycle. Please refer to my rant a couple paragraphs upward about WTF are packages implemented as modules?
Package Builder makes for an interesting model of shipping preconfigured clumps of functionality. The generated module is fetchingly simple enough to contemplate writing one by hand rather than use Package Builder to generate it for you. But then, what's the point, it should be easier to go click click with Package Builder to have it generate the package module. Where one might want to write it by hand is if there's something that Package Builder doesn't capture on its own. But the hooks mentioned on the project page should (one assumes) take care of any such need.
I'm pondering what it will be like to distribute version 1.1 of a module where 1.0 is in the field and being used by a zillion websites. In other words, how would you update existing installations? And I'm not really liking the picture in my mind.
Because Package Builder generates an object dump it doesn't seem likely it could know what's different between version 1.0 and 1.1. Suppose you modify a view between 1.0 and 1.1, how are you going to communicate the modification of that view to your customers? Especially if they themselves have modified the view that you shipped?