Re: [Arx-users] Configurations (and the ArX ArX archive)

[Walter Landry]

Kevin Smith <address@hidden> wrote:
> Walter Landry wrote:
> > That was a large part of the motivation behind the "super-tag"'s that
> > I mentioned earlier.  I always thought that configurations were
> > clumsy.  In the meantime, if you have any suggestions to improve the
> > manual, I'm all ears.
> 
> Ok. if the "config" command is going away, then I'll just focus on 
> improving the docs. If the command is going to stay, then I have a 
> suggestions for making it friendlier (see below).

It is definitely going away.  It is the next thing after crypto
signatures and Windows and OS X builds.

> The most important thing in documenting config is to provide a context. 
> What the heck is the purpose of this thing, and what is the basic mechanism.

I thought the purpose and mechanism is exactly what was explained in
Section 5.5.  The first paragraph was almost all about "purpose", and
the rest was about "mechanism".

> If I understand it, a project can have one or more "config" files, each 
> of which define a set of other related projects. You refer to that main 
> project as the "superproject", but it can still be a normal project, 
> too. By convention, the config file(s) would be stored in a project 
> subdirectory named "configs".

Correct.

> The user can use the config command to overlay those other projects into 
> the current workspace. There are "get" and "merge" options available, 
> which correspond to the arx commmands of the same name.

Correct.

> After that basic introduction, I would give the example from ArX. But I 
> would show the commands first, and only then show the arx.arx contents.

That sounds reasonable, in that people are more likely to have to deal
with someone else's configurations before they build their own.

> If that sounds reasonable, I think I could take a stab at actually 
> rewriting section 5.5. Let me know.

That sounds fine, although I wouldn't spend too much time on it.
Configurations will be disappearing.

> If the command is not being phased out soon, I would suggest splitting 
> it into two commands: config-get and config-merge. This avoids the 
> confusion of having certain options only apply to one or the other, and 
> also allows them to more closely map to the main get and merge commands.
> 
> Also, I think "config" is a poor choice (even though I can see where it 
> came from). I think it should be something more descriptive like 
> multi-get or overlay-get or subproject-get, or something like that.
> 
> I notice you have a bug in the tracking system to change the way config 
> is handled. If I understand that change request, it would create the 
> concept of a "superproject" that would NOT also be a normal project--it 
> would just be a shell...kind of like the multi-tag we discussed. I like 
> that direction.

Correct.  It is exactly what we were discussing.  I wrote that bug a
while ago as a place holder for whatever I come up with.

Walter