From Habari Project

Jump to: navigation, search



aka, Habari Package Manager.

Name It

It needs a name. list and sign your suggestions below. and mybe we can vote or something.

  • SuperDuperPackageManagementSystemForHabari --MattRead 14:43, 20 May 2008 (UTC)
  • hpm is a grand name --michaeltwofish 00:27, 21 May 2008 (UTC)


uses xmlrpc to make calls to repo/server.

  • packages.update
    • returns a list of packages, suitable for the current install.
    • params are version (timestamp of last update) and Habari_Version.
  • server.getInfo
    • return info about the server, name, description, etc..

more are planned but not implemented.


all packages are "hosted" on repos. HPM provides support for multiple repos.

The whole repo structure and API needs be thought out some more, It's kinda "hacked" in right now. See HabariPackageRepo_server class.


when the packages.update xmlrpc is made it store all info in the {packages} table in the DB. The package info can then be retreived and displayed to the user to provide "one click" installs/removes.

packages contain the folowing information:

  • 'name'
  • 'package_name'
  • 'version'
  • 'description'
  • 'author'
  • 'author_url'
  • 'max_habari_version'
  • 'min_habari_version'
  • 'archive_md5'
  • 'archive_url'
  • 'type'
  • 'status'
  • 'depends'
  • 'provides'
  • 'signature'

packages are unique by package_name, which is basically the packages "slugified-name". We should prolly make packages unique by a GUID like the beacon update thing.

the actual archive can be hosted anywhere, and does md5 checks to ensure it matches.

type is 0,1,2 for system,plugin,theme respectively. plugin and theme packages can only install to 3rdparty/plugins/ or 3rdparty/themes/. system packages can install to any folder on system, but must have a valid signature. the siganture validation would be done against the habari community server, and send off the md5 and signature to validate, or something...

status will be installed, available, upgrade, or conflict. upgrade meaning there is an upgrade available.


the archives (zip,txt,tar.gz currently supported) use the "PackageArchive" class to do all the archive fetching/manipulation. This class creates a new "ArchiveReader" based on the content type of the archive, and the archive reader does all the unpacking/file manipulation. Any number of ArchiveReaders can be supported and can even be plugins (or packages) themselves. This can allow for the distribution of non-ASL code.

Currently the TarReader is GPL and the ZipReader, uses dUnZip2, is unlicenced (one fo those "email me if you use it types"). TxtReader, to read single file txt files, is ASL.

You can register an ArchiveReader for a content-type like:

   PackageArchive::register_archive_reader( 'application/x-zip', 'ZipReader' );
   PackageArchive::register_archive_reader( 'application/x-gzip', 'TarReader' );
   PackageArchive::register_archive_reader( 'text/plain', 'TxtReader' );


Dependencies and Provides are planned...

packages will depend on and provide "hooks"...


  • write the server backend
  • write HabariPackages::get to work similar to Posts::get
  • implment tags or categories. categories might "limiting" but tags maybe too vague. we could display links for the most popular tags or something to filter the packages displayed. i dunno...
  • implement a theme browser and plugin browser. right now they are all grouped together. the interface is good for plugins, but for themes I would like to show the screenshots in a similar list.
    • this could be pretty easy with the hpm_packages admin template. we could just have another for plugins and themes.
  • integrate better with habari. right now it just copies files to disk and deletes them.
    • it may be better to do everything by the "base directory" instead of building the install_profile of every file as we do now. that would make it easier to call activation hooks and such.
    • How many actions should there be? "activate, install, deactivate, uninstall". for hpm I think we could narrow it down to simply 2: install (which also activates) and uninstall (which also deactivates). There is the argument that you may want to deactivate without uninstalling though..
    • Should we add the uninstall action to the plugins/themes page?
  • implement dependencies. should have requires, provides, and recommends.
Personal tools