Re: [Gnu-arch-users] Some plans about arch infrastructure in Perl

[Mikhael Goikhman]

On 12 Mar 2004 21:33:28 -0500, Aaron Bentley wrote:
> 
> Mikhael Goikhman wrote:
> 
> >On 11 Mar 2004 21:45:26 -0500, Aaron Bentley wrote:
> >
> >>Mikhael Goikhman wrote:
> >>
> >>>* axp - command line tool and wrapper for tla (Arch eXtended by Perl)
> >>
> >>aba's just 106 lines, and it would probably be shorter in Perl.  You'd 
> >>get 37 (and counting) extension commands for free, but since I don't 
> >>know Perl, I'd probably keep maintaining aba too.
> >
> >I wish we have as many tools as the developers are willing to maintain.
> >This is healthy for arch. These kinds of things are hard to be envisioned.
> 
> I agree with you on this.  But the multiplicity of tools can have a 
> downside: people don't know what's out there, and wind up rewriting the 
> same tool over and over again.  (For example, "aba branch-this" appears 
> to be the same as "tla fork", and they're both in the same package!)

Unifying sub-command names is a good thing indeed.

I will surely think deeply before actually starting to work on axp.
The most work will be on arch-perllib that maps all data into nice
hashes/objects and has a simple yet powerful interface.

> What I like about tlacontrib is the idea of unifying the collection of 
> tla tools, so people can find what's available more easily.  aba takes 
> this one step further by providing a unified way of finding and using 
> the available tools. 

> Perhaps the key point if you're considering writing an aba alternative 
> is that aba subcommands are simply scripts (or binaries, I guess) that 
> support this interface:
> foo exec $*: Perform their operation on the supplied arguments
> foo exec (-h|--help): Provide short help
> foo exec (-H)Provide long help
> foo desc Describe the script's function, in 'tla help' format

axp will be a gateway for subcommands, every subcommand is in its own
file that probably has the calling function, the test functions,
documentation in POD format and more. It is possible that all these files
are gathered into one large axp script on the built stage. I also thought
about doing the same with perllib *.pm classes, although it is trickier.
So, at the end (theoretically, not very sure it is good), a user may get
one executable to place in his $PATH on any system and it will just work.

Of course the mechanism will automatically provide common options for all
subcommands, like --help, --man (this creates the subcommand man page on
the fly and pipes it to $PAGER), --usage and maybe other.

[programming language stuff is skipped to avoid needless flame wars]

Regards,
Mikhael.