Eiffel Library Repository - Revision history

Paulb: /* Basic Structure */

2009-06-15T23:48:46Z

‎Basic Structure

Paulb: Added sections

2009-06-15T22:46:08Z

Added sections

Paulb: /* Overview */

2009-06-15T22:41:26Z

‎Overview

Paulb: Initial page

2009-06-15T22:40:58Z

Initial page

Paulb: Added initial page

2009-06-15T20:22:46Z

Added initial page

New page

{{UnderConstruction}}
[[Category:Eiffel Library Repository]]
[[Category:EiffelStudio]]

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

Placeholder for the Eiffel Library Repository description.

@@ Line 26: / Line 26: @@
 === Basic Structure ===
-[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.
+[[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.
@@ Line 34: / Line 34: @@
 [[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?!
 === Security ===
 Another issue is that of security. With repositories such as [http://www.macports.org MacPorts], 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 [http://www.ubunut.org Ubuntu], access to the main repository is forbidden and third-party repositories have to be used or [http://en.wikipedia.org/wiki/Deb_(file_format) .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.

@@ Line 12: / Line 12: @@
 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:
+[[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 <code>DIRECTORY/DIRECTORY.create_dir</code> 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.
@@ Line 24: / Line 30: @@
 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]] 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).
+[[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 [http://www.macports.org|MacPorts], 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 [http://www.ubunut.org Ubuntu], access to the main repository is forbidden and third-party repositories have to be used or [http://en.wikipedia.org/wiki/Deb_(file_format) .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.
+=== Security ===

← Older revision		Revision as of 22:41, 15 June 2009
Line 30:		Line 30:
	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?!		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 [[http://www.macports.org\|MacPorts]], 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 [[http://www.ubunut.org Ubuntu]], access to the main repository is forbidden and third-party repositories have to be used or [[http://en.wikipedia.org/wiki/Deb_(file_format) .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.	+	Another issue is that of security. With repositories such as [http://www.macports.org\|MacPorts], 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 [http://www.ubunut.org Ubuntu], access to the main repository is forbidden and third-party repositories have to be used or [http://en.wikipedia.org/wiki/Deb_(file_format) .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.

@@ Line 3: / Line 3: @@
 [[Category:EiffelStudio]]
 Got an idea what we should call it? Write your suggestions down in the [[Repository Name Suggestions]] page.
-Placeholder for the Eiffel Library Repository description.
+== Overview ==