Eiffel Library Packaging Policy

This document describes a policy for packaging, distributing and installing Eiffel libraries. The policy intends to facilitate the distribution and use of Eiffel libraries and provide a stable framweork for writing tools for distributing, installing and using Eiffel libraries.

The goals

The goals of this policy are:

  1. Support the versioning of libraries.
  2. Support having multiple versions of a library installed and easily switching between them.
  3. Define a standard library description file format (not XML-based) that supports describing library dependencies on other libraries in terms of versions as well as on shared binary objects (.so and .dll) and also Eiffel language versions and runtime environments.
  4. Define a standard directory structure for installation of libraries. Eg. on Linux: /usr/local/eiffel/<LIBRARYNAME>/<VERSION.
  5. Support installing and using Eiffel libraries with bleeding edge code from library repositories (svn, git etc.) alongside officially released versions of these libraries. Eg. on Linux: /usr/local/eiffel/<LIBRARYNAME>/<DEVELOPMENT-TAG>

Once these goals are established it will be possible to develop tools for maintaining and installing Eiffel libraries on a given machine as well as building server based repositories and distribution centers of Eiffel libraries.

An example

A Linux machine with Gobo, eposix and ejson could have an installation footprint like this:


Layered solution

A layered solution like dpkg and apt-get is nice.

At one level a package format for Eiffel libraries is defined together with conventions for how to install it.

At the next level one can define Eiffel package repositories and support for querying them and downloading Eiffel packages.

Example implementation of tools

Assume that Eiffel package repositories can be identified with a HTTP-based URL like


Each repository can have multiple packages and multiple versions of each package. On a client (developers) machine it should suffice to define a eiffel.package.sources file which lists all repositories that a client is interested in. For example a eiffel.package.sources file could look like this:


A HTTP interface to those package repositories could look like this:

Command Descripion Example
HTTP GET / Returns a list of available packages. HTTP GET  http://packages.eiffel.seibostudios.se => {'eldap', 'eclop'}
HTTP GET /<PACKAGE_NAME> Returns available releases of a given package. HTTP GET  http://packages.eiffel.seibostudios.se/eldap => {1.0, 2.0, 2.0-with-gravy}
HTTP GET /<PACKAGE_NAME>/<RELEASE_TAG> Returns the package with the given release tag. HTTP GET  http://packages.eiffel.seibostudios.se/eldap/2.0-with-gravy => eldap-2.0-with-gravy.bz2

The eiffel.package.sources file can be edited manually or updated via a command line tool like:

$ eif-get add http://packages.cool-eiffel-stuff.org

A list of current repositories can be obtained with:

$ eif-get list

The tool could read the eiffel.package.sources file and the query the eiffel repositories and return information on available packages:

$ eif-get update
Updating info on packages at:
http://packages.eiffel.seibostudios.se ... ok. 2 packages found.
http://packages.dev.eiffel.com ... ok. 1 package found.
http://packages.gobosoft.com ... ok. 1 package found.
http://packages.berenddeboer.net ... ok. 1 package found.

It could list available packages ('i' meaning installed):

$ eif-get packages
- eldap-0.1 [http://packages.eiffel.seibostudios.se]
i eldap-0.2 [http://packages.eiffel.seibostudios.se]
- eldap-0.3 [http://packages.eiffel.seibostudios.se]
  eclop-1.0 [http://packages.eiffel.seibostudios.se]
i eclop-2.0 [http://packages.eiffel.seibostudios.se]
i eclop-2.0-with gravy [http://packages.eiffel.seibostudios.se]

And install packages:

$ eif-get install eldap-0.3
Installing eldap-0.3 [23 KByte] ... ok.