Trail: Home >

Goals and Ideas

Here's a collection of goals and ideas for the Cowry project.

Multi-component Applications

Bundle packaging is fine when what you're packaging is just a single application. But when your software package actually consists of an application, a framework, several plugins and a preferences pane, you'll have to use an installer after all. In most cases that also means your application is no longer self-contained, and un-installing becomes tedious, too.

The ultimate goal here is to allow all components of a package to reside within the application bundle, and have the Cowry system track the components and take appropriate maintenance steps automatically. The user should be able to run applications right out-of-the-box, and be able to move them around the file system as she likes.


A bundle appears as a single file once it is on the target computer, but getting it there is somewhat difficult, since technically, it is not a single file. Today, most Mac applications are delivered as disk images that are downloaded over the Internet. The user then double-clicks the image to mount it, and drags the contained application to a folder on the hard disk.

Some applications are packaged using other general-purpose archive formats, including StuffIt, ZIP or the Unix-style .tar.gz. Installing such an application still requires the user to de-compress the archive, then drag the resulting application into place.

To improve this, the Cowry system would use a widespread archive format (.zip or .tar.gz), but give the files a different file extension. Double-clicking such an archive would open the Cowry application, present some information about the application, then ask for where to install the application (e.g. system-wide in /Applications or just for the current user).

Since no application code is executed until the user acknowledges the installation and actually runs the app, it would be safe to have the web browser open the archive automatically after downloading. (This is not the case with disk images, which may contain malicious code that automatically executes as the image is mounted.)

Automatic Updates

Many Mac applications today have a built-in function to automatically check for updates. There are several problems with that:

The solution is clear: Remove update checking from the individual applications. Instead, put the necessary information inside the bundle in a format that can be read by a generic, external updating application. Any feature implemented there would automatically benefit all applications.


Help books for the Mac OS X Help Viewer reside inside application bundles. Many developers also include their ReadMe and License files inside the application, making them available from the Help menu. There's only one problem with that: users must run the application to access the documentation. So some developers put another copy of the ReadMe or documentation on their distribution disk images, outside of the application.

To avoid this duplication, Cowry could provide direct access to an application's documentation using a Finder context menu extension. The Cowry framework would also include library code to display ReadMe files and other documentation files inside the application, plus code to show welcome messages on the first run.

Unix Software

Mac OS X uses bundles only for GUI applications and Mac-specific packages. Command-line Unix software is still organized in a traditional Unix directory tree, invisible to the casual user. Mac applications that include supportive command-line tools need to install these in some way. Cowry could solve that problem by tracking the locations of the bundles containing Unix items, maintaining symlinks in a designated directory and adding that to the appropriate environment variables (e.g. PATH).


While Mac OS X supports bundles per design, other popular platforms do not. One goal of the Cowry project is to make the bundle mechanisms available on Unix platforms as an alternative to traditional package manager formats like .deb, .rpm or .pkg. Eventually, Cowry might even spread to Microsoft Windows platforms.

Build Tools

The build tools usually used in the Unix world — make, autoconf, automake, libtool — aren't really helpful when you're packaging software for distribution. They also have lots of private problems and significant inertia when it comes to supporting new platforms and features.

A build tool that has full knowledge of which files make up the package, how they are built and where they should be installed could ease the lives of developers, packagers and users alike. It would also ease building bundles instead of traditional packages, and could support building Mac OS X style frameworks for library packages.

Work on such a tool was spun-off into a separate project named pond.