itla (was Re: [Gnu-arch-users] etla [Was: Testbed for OverArch])

[Tom Lord]

    > From: address@hidden

    > Tom, to get it clear for us (well me), where do you feel
    > functionality like the following example should be implemented ?

    > 1) tla
    > 2) oarch
    > 3) distro level (or even company level)

    > My example problem: tla import gives me an error when I forgot
    > an init-tree, I would want a question at that point (at import
    > time) to do the init-tree without typing.

How about:

    1.5) itla

Here's what your example suggests to me:

ITLA is a customizable, extensible, self-documenting, interactive
front-end to tla.  It's useful on its own as a command line program
and, in combination with other tools, it can serve as a "driver"
program for a GUI, curses, and Emacs-based interfaces.

Typical command line usage is illustrated by:

        % itla
        (itla) -!-

Run without arguments, you get an itla prompt (the "-!-" represents
the cursor). 

Self documentation:

        (itla) help

        Help Topics
          concepts      general introduction
          user          user settings
          tree          project tree management
          inv           file inventories
          changes       changeset commands
          transactions  archive transactions
          [....]

        Use the "glossary" command to look up unfamiliar words.

        (itla)
        (itla) help changes

                   changeset : compute a whole-tree changeset
                     mkpatch : (alias for changeset)
             apply-changeset : apply a whole-tree changeset
                     dopatch : (alias for apply-changeset)
              show-changeset : generate a report from a changeset

        
        (itla) help changeset
          [ tla changeset -H output passed through a more(1)-style
            filter]

Interactive Prompting

        (itla) get
        project name?: tla
        branch? (main): devo
        version? (1.1): 
        destdir? (tla--devo--1.1):
        * getting tla--devo--1.1 to directory tla--devo--1.1

Complex Commands

        (itla) cd ~/wd/my-project
        (itla) import
        * Tree not initialized.

          init now (y/n)? y
          category: my-project
          branch (main): 
          version (1.0): 0.1

          tagging-method (TAGLINE,explicit,names): 

        [....]

Uncommon Options

        # normal invocations ignore them:
        # 
        (itla) init-tree
          category: foo
          branch (main): 
          version (1.3):
          * initializing

        # extended invocations don't:
        (itla) init-tree?
          archive (address@hidden):  address@hidden
          category: foo
          [....]

It can also be used only semi-interactively:

        % cd ~/wd/my-proj
        % itla import
         [...]
          init now (y/n)? y
         [...]        
        * import complete
        % 

It would be a good idea to write the argument prompting parts of itla
as declarations -- and to do the same with the outputs.

For example, if you'll forgive my pseudo-lisp syntax:


        (define-command (init-tree version dir nested?)

          (help-message   (category tree)
                          (% tla init-tree -H))

          (parameters   (version        new-fq-version-name)
                        (dir            (extended existing-directory))
                        (nested?        (extended y-or-n)))

          (output       plain-text)

          (run-tla "init-tree"
                   (if dir (list "-D" dir))
                   (if nested? (list "--nested"))
                   version))

with all of the prompting such as:

        category: foo
        branch (main): 
        version (1.0):

being driven from declarations like:

        (parameters     (version        new-fq-version-name)
                        ...)



Aside from making commands easier to maintain, a declaration-driven
system like that opens up the possibility of using itla as a
GUI/cursors/emacs driver.

Those "more graphical" front ends don't have to keep being extended
for every new interactive command.  Perhaps they can be for selected
commands but a lot of mileage could be gotten just out of generically 
translating a 

        (parameters     (version        new-fq-version-name)
                        ...)

declaration into a dialog box or comperable form.  No special GUI
support needed for `import' -- just generic support for "prompt for
new version name", "promopt for existing directory", "prompt for
y-or-n".

The output declarations:

        (output         plain-text)

have a similar purpose.   A GUI might just display "plain-text" 
but for:

        (output         text-with-arch-revision-names)

scan the output for substrings matching arch revision names and
turn those into hyperlinks.

If the hooks to support GUI/curses/Emacs front ends are really well
done, that solves another problem that Stephen had been complaining
about:  changes to the tla command line syntax.   ITLA would be
a single place where such changes could be fixed for all those
data-driven graphical front-ends at once.

Does this sound doable to you and more importantly, does it sound
useful?


-t