Difference between revisions of "Eiffel Library Repository"

Revision as of 13:40, 15 June 2009

Naming The Repository

Got an idea what we should call it? Write your suggestions down in the Repository Name Suggestions page.

Overview

Here at Eiffel Software we are planning something big and exciting that we hope will exponentially grow the availability and contribution of libraries for Eiffel, and before anything really gets started we wanted the most important feedback for a community focused project - community feedback.

We are in the very early stages of planning so this is your chance to put forth ideas and comments of what you would like to see and how you would like this to work.

We believe Eiffel would benefit from a centralized Eiffel library repository and an accompanying tool set for querying, downloading, and uploading [Repository Package|prpackaged] libraries. In the same vein popular Linux distributions use package managers, the Eiffel compiler should be able to reference a package library using a human readable, location agnostic, versioned library, and everything else is done for you, such as actually resolving the location of the package library. We want the process to be as simple as possible so user interaction would be kept to a minimum. Here is a quick outline of what we have planned for the first revision, this is a high level view for brevity:

Eiffel Software would like to have a first version of the repository available in due course for the next release (post 6.4). Although we would like to implement every feature under the sun for the initial release, we'll have to use our digression to prioritize the first release features. There are many features we would like to support, as well as some we don't even know about yet (this is where you come in), which could make the initial release of the infrastructure/tool set.

The initial idea is to host the packages in a repository using a single master server and potentially a number of mirrors. End users will synchronize with the repository to download package metadata to a local cache, known by EiffelStudio and the Eiffel compiler or configured via a variable or configuration file. The downloaded information will not be the packages themselves, but just package information (name, version, description, dependencies, etc.), to ensure that synchronization is a swift process and to save bandwidth utilization. End users can then use a provided tool set, distributed with the Eiffel compiler, to download required packages or search for packages (eventually searching for specific functionality - i.e. "creating directories" and it giving back DIRECTORY/DIRECTORY.create_dir from EiffelBase). The process of downloading a package will also pull down any dependent packages as to ensure compilation is successful upon first use.

For a future revision, the single master server/mirror paradigm may be enhanced to support community public repositories, allowing third parties to host their own server and serve their own libraries in a like manner to apt on Ubuntu. End users will then be able to configure a local cache into which they can download package metadata. The client tool set will then be able to search and download packages stored in a third-party repository.

[Repository Package|Packages] (pre-packed Eiffel libraries) will be authored and structured in a known format/directory hierarchy containing the Eiffel source, resources, external dependencies (such as header files, libraries, external code needing compilation) and build scripts. A package configuration file will describe the package, its dependencies on other packages, and a version policy for each dependent package.

Some packages support a single platform, some all, and some just a specific set of platforms. The package repository should respect this and each package should make aware the platforms it is applicable to. It is the responsibility of the package author to include any platform dependent external resources (binary libraries) as well as any platform independent externals, which will be built once downloaded on an end-user's system. If applicable, irrelevant platform specifics should be omitted when downloading the library, again saving bandwidth, space on the end-user's system, and cleanliness of the downloaded library itself.

[Repository Package|Packages] may need to perform post-install setup or [Repository Package#Build Script|building] of platform independent sources (EiffelNet is such an example). These packages should contain [Repository Package#Configuration File|configuration] information on how to build/install and clean/uninstall once a package is downloaded on an end user's system. Cleaning/uninstalling will occur when a package is updated or removed respectively.

[Repository Package|Packages] will have to abide by a [Repository Package#Versioning|versioning] policy for the sake of compatibility. Each package will optionally contain a minimum/maximum version number of the Eiffel compiler, however packages should be smarter and support a wider range of compilers by utilizing the features of ECF. Packages depending on other packages should specify the minimum version of a referenced library, and optionally a maximum version (see below why this is important).

This all sounds pretty boiler-plate for a package repository, and it is. Package repositories work well, so why would we try and change that?!

Another issue is that of security. With repositories such as [[1]], not just anyone can simply apply and start uploading a "port". In fact, developing a port, uploading it, and maintaining it is very restrictive. A port has to be sent in and a moderator or someone with commit rights will integrate if for you. In [Ubuntu], access to the main repository is forbidden and third-party repositories have to be used or [.deb] files have to be downloaded from another source. This all sounds very inconvenient. The repository should contain a means to allow package maintainers to upload new versions and no one else. This can be accomplished via an account manager, hosted by the package repository, or using a private/public key pair to be embedded in the package when uploaded or supplied as an argument to tools in the tool set.