Re: [Gnu-arch-users] Re: talk amongst yourselves: "iterated" operations over configs

[Tom Lord]

    > From: Robert Anderson <address@hidden>

    > [ideas about commands that iterate over the subtrees of a
    >  config]


A few thoughts and rhetorical questions:

1) Should this new mechanism also support iteration of subtrees
   chosen by some means other than via a config?  (E.g., "all
   subtrees", "first-level subtrees", "named or matching subtrees",
   "list of subtrees on stdin".)?



2) I much prefer (between these two) the idea of a prefix command to a
   per-command option.  In other words, I like:

        tla map-subtrees <cmd>

   better than:

        tla <cmd> --map-subtrees

   because that suggests that the iteration is doing something 
   generic and regular -- that it captures some useful general
   principle about how to iterate tla commands over subtrees.



3) Exactly which commands does this apply to and, for each command, 
   what are the detailed implications for the processing of arguments
   and options to those commands?

   Here are two examples:

        a) in a "commit subtrees" operation, how are log files
           handled?

        b) Let's suppose that I have tree in which all subtrees have
           the branch-label `release' in their default tree version.

           I happen to know that for each subtree, there is another
           version having the same category and version, but the
           branch label `devo'.  

           Can I use this new mechanism to ask `whats-missing' from
           the `devo' version for each subtree?



4) Exactly how is the output of commands treated?

   Is it simply concatenated?  Is it concatenated with separators to
   label each section with the subtree path?  Are sections indented?
   Is output folded together in some way?  (Simply concatenating
   output would not work well for the `whats-missing' example.)



5) I most prefer the idea of not adding either an iteration command 
   or iteration options to commands.   Why is that?

   I don't think that questions (1), (3), and (4) above have
   reasonable, finite answers.    

   Question (3) is particularly telling because I think that if you
   think about, pretty quickly you'll decide that a complete scripting
   language is needed to control the handling of options during
   iteration.

   It may be the case, as it has in the past, that this or that
   command needs a tweak to make its output easier to use in a script 
   or to make its argument syntax friendlier to xargs -- those kinds
   of changes are fine.



Part of the problem, I think, is the absense of a demonstrated itch
that is proportional to the ambition and generality of the proposed
family of solutions.   For example, one itch is that:


        tla catcfg CFG | awk '{print $1}' | xargs tla ....

is too many commands.

Well, I can certainly see adding an option to catcfg to limit its
output:

        tla catcfg -p CFG | xargs tla ....

just as a small convenience.

Either that change would be sufficient to scratch the itch or it
wouldn't.  But if it isn't, why exactly?  Because of the need to type
"| xargs tla"?  presumably not --- but more likely because the
simple-minded iteration that xargs will do here isn't sufficient.
Instead, for this or that command, maybe there will be a need to
compute changes to the options for each subtree; perhaps there will be
a need to massage the output one way or another.  The per-command
details matter a lot here but most of the discussion seems to be
focussed on the trans-command generalities.

Command by command, option by option:  what do you want iteration to
do and why?

If you have good answers to that, and a general pattern emerges other
than one covered by `| xargs tla', then that may be a good case for an
iteration command.

If no general pattern emerges, then it's a question of maybe adding
per-command options for iteration.   But again, in each case, what
would that option do that would justify its being in tla rather than
in a trivial shell script over it?

I don't mean to be too negative here.   Like several others on the
list, I think that configs are an underdeveloped idea.   I'm all in
favor of building up conveniences and additional features around them.

I'm just very skeptical of leaping into the idea of implementing a
simple-minded subtree iterator.  It feels more to me like it would be
implementing a _symbol_ of the features we _vaguely_ want than it
would feel like implementing _tools_ which provide features we
_certainly_ want.


-t