Question about Package Builder

Can Package Builder handle a creating a full directory with all it’s files in one resolver action?

If I want the package to create a manager/assets/captcha directory and all it’s contents, what would be the appropriate source and target field entries in the Resolver?

The default target that comes up is: return MODX_ASSETS_PATH . ’snippets/’; which can’t be right.

I’ve tried some things and the package is built OK but won’t install.

BTW, typo on the Package Builder page: "remove provisioners" should be "remote provisioners"

Just a thought -- It might be good the have "Package Installer" on the main tools menu rather than "Workspaces" or just call it Package Manager and put Package Installer and Package Builder under it. It would be a lot easier to find. Also, it’s hard to be sure about what "update package" and "delete package" actually do.

I tried to post these issues on Jira but my current internet connection is marginal and I couldn’t get them to go through.

Quote from: BobRay at Aug 16, 2008, 04:36 AM

Can Package Builder handle a creating a full directory with all it’s files in one resolver action?

If I want the package to create a manager/assets/captcha directory and all it’s contents, what would be the appropriate source and target field entries in the Resolver?

The default target that comes up is: return MODX_ASSETS_PATH . ’snippets/’; which can’t be right.

I’ve tried some things and the package is built OK but won’t install.

This gets a little tricky, but basically, you would want to make the source be MODX_MANAGER_PATH . ’assets/captcha’ and the target would be "return MODX_MANAGER_PATH . ’assets/’;"

Quote from: BobRay at Aug 16, 2008, 04:36 AM

Just a thought -- It might be good the have "Package Installer" on the main tools menu rather than "Workspaces"  or just call it Package Manager and put Package Installer and Package Builder under it. It would be a lot easier to find. Also, it’s hard to be sure about what "update package" and "delete package" actually do.

Workspaces, though it probably won’t be functional until after the initial 2.0.0 release, represent unique core "workspaces".  This will allow advanced users and developers to test various sites on different core installs at the click of a button.  This will also be an important part of core upgrades in the future.  The concept is similar to the Eclipse IDE where you can keep multiple configurations with different core versions or sets of extensions installed and switch between them by selecting a different workspace.

With that in mind, I think it makes sense to move all the Transport Package features under Workspaces, since packages themselves will be installed by (though not necessarily to, in the case of packages that install things into the web or another custom context) a specific Workspace.

What happens during intstallation when a package contains a file, dir, system setting, or element that already exists?

Overwrite?
Skip?
Abort Installation?

BTW, the Workspaces thing sound really exciting and the current Package system is an amazing piece of work.

Files would be overwritten if the PHP user has permission, directories would not be affected. Data objects that are contained in vehicles can be configured for various behavior, including defining which field needs to be unique, or whether keys need to be preserved. Consider this code to package a plugin which should be unique by name and not by id:

After failing with a complex package, I created a new minimal package containing only one modsystemsetting and no resolvers. The build goes fine but I can’t get the package to install on a fresh site.

I tried with a new system setting key and with an existing one that I deleted before the install. Either way the package fails to install.

Has anyone tried installing a package created with Package Builder lately?

The system settings table has changed significantly, and you likely need to change the way you create the modSystemSettings objects. I’ll get back to working on packages this week, once I’m done with battening down the security hatches.

BobRay,

Yeah, we’ve adjusted things quite a bit recently, and actually you wont have to manually assign Settings to packages anymore - you’d just select a namespace and the settings with that namespace will be auto-packaged in. It’s a little bit in transition currently; so I’m sure we might run into some bugs here and there.

The transport system is one of the top priorities for me this week, so expect to see more commits related coming.

I’m looking forward to a new package builder. A browse button for the source in "add resolver" that automatically fills in source and guesses at the target would be sweet. At this point, though, I’ll settle for something that works. I’ve been trying to build the captcha package for several days now.