The Collaboration Wiki for Packaging - erlware-questions

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion The Collaboration Wiki for Packaging
Received-SPF: pass (google.com: domain of ericbmerr...@gmail.com designates 209.85.213.52 as permitted sender) client-ip=209.85.213.52;
Received-SPF: pass (google.com: domain of ericbmerr...@gmail.com designates 10.50.88.198 as permitted sender) client-ip=10.50.88.198;
Date: Thu, 01 Mar 2012 16:27:54 -0600
Message-ID: <87r4xct0r9.wl%ericbmerr...@gmail.com>
From: Eric B Merritt <ericbmerr...@gmail.com>
To: Tim Watson <watson.timo...@gmail.com>
Cc: Eric B Merritt <ericbmerr...@gmail.com>,
	erlware-questions@googlegroups.com
Subject: Re: The Collaboration Wiki for Packaging
In-Reply-To: <CALhYyxMOsMtwG-bYFMMZZyq9CuKOM+ghHtk+8KOfvjZDkxo...@mail.gmail.com>
References: <CACGM6H-sY4_z9vr1XuHO6U5gqkBKjao7u_qtVeCxLf8nBEi...@mail.gmail.com>
	<426E741E-FDB4-4C57-A42F-946C1F71A...@gmail.com>
	<CACGM6H8ZT0vP+BQx8DnkAbZLdK1xMMvtkRtjK8cYb6c26Vn...@mail.gmail.com>
	<CALhYyxOSiuWMw7bdA9C-C=qYthbaSJYRftsHHKwGnJxVL1z...@mail.gmail.com>
	<CALhYyxOzjKj2wHssvv7Sp58CMC1JXNG9PU1McqET80=tjzk...@mail.gmail.com>
	<87pqcwghn2.wl%ericbmerr...@gmail.com>
	<CALhYyxMOsMtwG-bYFMMZZyq9CuKOM+ghHtk+8KOfvjZDkxo...@mail.gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/23.3
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

At Thu, 1 Mar 2012 22:10:05 +0000,
Tim Watson wrote:
>=20
> I was just starting to think I needed to reconsider my position in
> light of the 'lots of little tools' approach - not be so monolithic in
> my perception of the process and all that - and it occurs to me that
> if some of our outputs are lists of file system paths we might be ok.
> I come on here to suggest it and voila, you've read my mind.

Its good to be on the same page.

=20
>=20
> > It would be cool if each of these could read their inputs on standard
> > in and write the outputs to standard out as well.
> >
>=20
> Yes definitely. I'm almost inclined to say that should be the required
> unix-y interface, so that people who're using Make (and similar tools)
> can still get value out of each and every one of these tools as they
> see fit.

I agree lets make that a requirement.=20
=20
> > **manager**:
> >
> > Â Inputs: a Â list of repos?
> > Â outputs: local index + basic local repo structure
> >
>=20
> Inputs: you mean a list of 'remote indexes' here right?=20

Yes. lets adopt that terminology.

> The word
> 'repo' is overloaded and implies storage more than anything else. But
> yes, I think a list of repos is fine.
>=20
> Flags: -f <filename>   read the list of repos from <filename> instead of =
stdin?

Sure. It should also read configuration files as well.=20

> Question: how are the repos specified? As a URL or as something else?

I think all the DVCSs support urls, so lets just use those. We can fit
the plugin concept around those urls.


>=20
> Question: this guy is presumably not writing to stdout, as it is
> creating directories on disk etc. So perhaps the stdout stream should
> contain the root directories and/or locations of these?

Thats a good idea actually.=20

>=20
> > **solver**:
> >
> > Â Input: Constraints are by their nature not OTP but we should try to
> > Â fit them in as seamlessly as possible
> >
> > Â Output: Should be a rel or relup file with organization annotation
> >
> >
>=20
> Yes that output sounds very reasonable. This is the area we've spent
> the least time thinking about the inputs for.

It might also take the directory of the repo as part of its
input. That way it could be linked to the above. Along with command
line options as well of course.


>=20
> > **fetcher**:
> > Â Inputs: a rel or relup file
> > Â Outputs: A list of code paths for the various dependencies
> >
>=20
> Absolutely - this is a great idea. What about where you're in an OTP
> application/library project and want to fetch your dependencies?
> Should we still work off a rel file out of the solver? I guess it
> doesn't matter that the rel/relup file is not needed, as we can still
> use it as an artefact in our process if we want to.

In this case the rel file just serves as a carrier of dependency
information. I think that works whether you have a single app or an
entire release. I dont think there is any need to invent something
ourselves that carries the exact same information.

>=20
> >
> > **builder**:
> > Â Inputs: A project that contains a rel+/relup file, a list of code pat=
hs for dependencies
> > Â Outputs: A built otp application(s) + updated list of codepaths
> >
> >
>=20
> Cool, I like this. As we've discussed before though, not every project
> is a release - sometimes it's just an application or a library. We
> need to support those use cases as well, so the rel/+relup can't be
> mandatory.

As I said above we need something to carry that information. Using a
dotrel makes more sense then inventing something ourselves. You can
have one without actually using it for anything else.

>=20
> >
> > **assembler**:
> > Â Inputs: A rel/+relup, A list of codepaths
> > Â Outputs: An OTP Release directory structure
> >
> > **packager**:
> > Â Inputs: An OTP Release directory structure
> > Â Outputs: A dist tarball (debian package, rpm etc)
>=20
> Ok I'm fine with these. Also the packager needs to support packaging
> plain applications/libraries as well as releases.

if by applications you mean OTP Applications of the active and
inactive variety (curse erlang's name overloading) then I am on board.

>=20
> **publisher**
> > Inputs: A dist tarball and choice of index to publish to + the users pe=
rsonal configuration (passwords, etc)
> > Outputs-1: an HTTP request to github/bitbucket/nexus/etc to upload/stor=
e the publication metadata in an index
> > Outputs-2: an HTTP request to github/bitbucket/nexus/etc to upload/stor=
e the binary artefact online

Absolutely.

There are probably tools for a repository maintainer as well. For
pulling merge requests, verifying signatures and the like. To come up
with something we forward to the erlang-questions list we dont need to
detail that. It is something we will want to keep in mind though.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
