Release config file syntax

[Gordon Tyler]

On Tue, October 12, 2010 12:18 pm, Vincent Ladeuil wrote:
> Wow, that was fast :)
>
> A bit too fast even, I wanted to collect the data before starting
> implementing any code :)

I figured I should get the basics down so we get the ball rolling. I can
promote this into a full LP project and assign ownership to the Bazaar
team so we can all work on it.

> Anyway, rough review:
>
> I don't like:
>
> - reimplementing a config file on top of configobj, we already do that
>   in bzrlib.config and the idea was to *reuse* that as much as we can,

bzrlib.config adds a lot of cruft on top of the configobj API that seemed
really unnecessary for this project. I don't have the code in front me
right now so I can't go into specifics, but I did look at using
bzrlib.config first but decided that using bzrlib.util.configobj directly
was better.

> - the use of embedded sections, we don'support them in the
>   bzrlib.config, that's why I mentioned using dotted names instead.

I really like the embedded sections, they make the code extremely sane.
Why reinvent the wheel when configobj can do it?

> I like:
>
> - the higher level objects like Package and maybe a ReleaseConfig that
>   will be specific to each platform (as in presenting the relevant
>   options from the config file),

Yup, that's the intention. When you ask the ReleaseConfigs object, for the
config of a particular platform, you get a ReleaseConfig object back which
has a list of Package objects for the particular version of each plugin
and package that the platform is configured to use.

> - the helpers for fetching and installing the dependencies and the
>   plugins.

Currently, these are just simplified copies of the code in
fetch-externals.py from the Mac installer. I would like to improve this to
be more smart about when they download/update and to provide a feedback
mechanism so that when you're building the installers, it doesn't sit the
with a blinking cursor while it gets a gajillion revision branch
(lightweight checkout, but still could be lengthy).

> I'm unclear on how to share the *code* between the various packaging
> projects though...

Probably as a pre-build dependency like a compiler, pyrex, etc.

> On the other hand, since the OSX installers already use sub-directories
> (and I suspect the windows installers do the same), we may want to use
> scmproj or bzr-externals...and we may as well package them no ?

I have no idea how scmproj or bzr-externals work. I'm reluctant to
shoehorn this into something that wasn't designed to manage this. And I'm
not sure what you mean by packaging?

Ciao,
Gordon