-
Notifications
You must be signed in to change notification settings - Fork 2
A New Infrastructure for Erlang Build and Packaging
- Packages (OTP applications, libraries and releases) should be published as pre-built binary artefacts (archives)
- Packages must be accessible via an HTTP URL
- Packages should be richly described using metadata
- Package metadata should be published in a remote index
Any more for this section?
- Remote Index
- Local Index
- Local Repository
- Erlang Consumable App Dir
- A remote index will be a repository of human readable metadata, organized by directories
- The index will be stored in git and targeted initially at github
- Actual package tarballs will be stored in arbitrary locations with urls in the repository metadata pointing to those locations
- Indexes are peers and there is no 'central' repo
All metadata will be organized around 'Organization' names. So the namespace for an OTP app is organization, app name, version. Where the same app name can appear in multiple organizations.
The organization name must, of course, be flattened out (i.e., removed) by the time the dependencies are resolved for use in an OTP release.
The local index is a searchable, queryable cache of all Remote Indexes that the user has expressed interest in. It allows the various tools to resolve dependencies, even when internet access is unavailable.
As an option, the tools may make use of a local repository that serves as a cache of what is in the Remote Repositories. It has a structure similar to the Local Index, but also contains resolved binaries. This should never be used directly by any erlang systems as a source for code.
When a set of dependencies are solved they are resolved down to a single global namespace (the exact same scheme erlang uses). These dependencies are then resolved into an Erlang Consumable App Dir. This can be used as a source of code for the Erlang VM.
- Convention over Configuration
- Everything is configurable
No tool should hardcode a path. All paths must have both sane defaults and the ability to be overridden both via configuration files and the command line.
- Certain behaviours can be overridden by user defined modules
- Overriding behaviours (i.e., plugins/extensions) can be obtained as dependencies
manager: serves the function of interacting with the remote repos, index management, resolution. apt-get for erlang.
solver: the dependency solver. Given a set of constraints and one or more indexes resolves all dependencies to hard versions and outputs those in a consumable way.
fetcher: this may be integrated with the manager (probably will be). Given a set of app-name/version repos will fetch the correct binary for those repos to a specified location.
builder: The builder, given dependencies and a project dir will build binaries. This will probably be served by rebar and/or the build functionality of sinan.
assembler: The assembler. Given resources above and build code assembles an erlang release building the script, rel and boot files as needed.
packager: This serves to package up a release for distribution. In any number of formats.