Our story so far

[Eric B Merritt]

Parts of the Packaging Machine
------------------------------

* 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.

[Tim Watson]

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?

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.
>

[Eric B Merritt]

At Mon, 27 Feb 2012 19:01:34 +0000,

Tim Watson wrote:
>
> 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?

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.

[Chris Duesing]

one comment, inline below:

On Mon, Feb 27, 2012 at 1:38 PM, Eric B Merritt <ericbm...@gmail.com> wrote:

At Mon, 27 Feb 2012 19:01:34 +0000,

Tim Watson wrote:
>
> 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?

sure though I would want to type less on the command line.

I see you have stuck with elra, erlb, etc. on the wiki, and I would like to cast a second vote for aardvark (or something easier to type). unless each tool has a memorable name that is based on its purpose, it is going to be extremely difficult for people to communicate about. succinctness on the command line should not be the driving factor in naming (and tab completion should keep it to 3-4 keystrokes anyway). 

[Eric Merritt]

>> At Mon, 27 Feb 2012 19:01:34 +0000,
>> Tim Watson wrote:
>> >
>> > 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?
>>
>> sure though I would want to type less on the command line.
>
>
> I see you have stuck with elra, erlb, etc. on the wiki, and I would like to
> cast a second vote for aardvark (or something easier to type). unless each
> tool has a memorable name that is based on its purpose, it is going to be
> extremely difficult for people to communicate about. succinctness on the
> command line should not be the driving factor in naming (and tab completion
> should keep it to 3-4 keystrokes anyway).

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.

>

[Eric Merritt]

I have changed the names to be generic titles for now. Btw, the page
is editable by anyone so feel free to make changes.

[Tim Watson]

Cool, thanks. I'm just starting to review now.

[Tim Watson]

Have added several questions and made some minor amendments. Please review them when you get a chance.

Cheers,

Tim

On 29 Feb 2012, at 20:36, Eric Merritt wrote:

[Tim Watson]

Sorry, just to mention. I made some changes to distinguish between repository (storage) and index (metadata storage). I hope this makes sense to you - I found it confusing talking about a remote repository (which is the index) and a local repository which stores the artefacts.