* Remote Repositories
* Local Index
* Local Repository
* Erlang Consumable App Dir
#### The Remote Repositories
* The repository will be a repository of human readable metadata,
organized by directories
* The repositories will be stored in git and targeted initially at github
* Actual package tarballs will be stored in arbitrary locations with
urls in the binaries pointing to those locations
* Repositories are all peers, there is no 'central' repo
##### Organizations and namespacing
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 must, of course, be flattened out by the time the
dependencies are resolved to an app dir.
#### The Local Index
The local index is a searchable, queryable cache of all Remote
Repositories that the user has expressed interest in. It allows the
various tools look at the local index to resolve dependencies.
#### The Local Repository
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.
#### Erlang Consumable App Dir
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.
Tools
-----
##### Goals
* 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.
Repository Management Tool
--------------------------
**erlp**: serves the function of interacting with the remote repos,
index management, resolution. apt-get for erlang.
**erls**: 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.
**erlf**: this may be integrated with erlp (probably will be). Given a
set of app-name/version repos will fetch the correct binary for
those repos to a specified location.
**erlb**: 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.
**erla**: The assembler. Given resources above and build code
assembles an erlang release building the script, rel and boot files
as needed.
**erld**: This serves to package up a release for distribution. In any
number of formats.
What name for the overarching tool set? Given a name, say (for the sake of example) we call it 'aardvark', then can we simply name the individual parts 'aardvark'-<toolname>, so we get ...
aardvark-package(r)
aardvark-resolver
aardvark-assembler
or something to that effect?
In addition to what you've stated thus far, we've also got
- each tool has two APIs
- one on the command line (which presumably uses the next one...)
- one for Erlang code to consume
> --
> You received this message because you are subscribed to the Google Groups "erlware-questions" group.
> To post to this group, send email to erlware-...@googlegroups.com.
> To unsubscribe from this group, send email to erlware-questi...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/erlware-questions?hl=en.
>
sure though I would want to type less on the command line.
> In addition to what you've stated thus far, we've also got
>
> - each tool has two APIs
> - one on the command line (which presumably uses the next one...)
> - one for Erlang code to consume
yes. exactly.
At Mon, 27 Feb 2012 19:01:34 +0000,
Tim Watson wrote:sure though I would want to type less on the command line.
>
> I'm 100% on board with this.
>
> What name for the overarching tool set? Given a name, say (for the
> sake of example) we call it 'aardvark', then can we simply name the
> individual parts 'aardvark'-<toolname>, so we get ...
>
> aardvark-package(r)
> aardvark-resolver
> aardvark-assembler
>
> or something to that effect?
Those are still just placeholders. We haven't really talked about
trying to come up with a name so I left them alone. I will change it
to resolver/assembler etc until we can get a better idea of an actual
name.
>
Cheers,
Tim
On 29 Feb 2012, at 20:36, Eric Merritt wrote: