Re: [Gnu-arch-users] Re: Tla spork

[Tom Lord]

    > From: address@hidden (James Blackwell)

    > On the general issue (avoid environment variables), you and I
    > are in strong agreement. But I think this is the exception that
    > proves the rule. People such as myself are in different contexts
    > in different ttys.

Well, yeah -- it *might* be.  But can we get some more experience with
the hat foo before we decide it is?

Remember that we used to have support for a $ARCHIVE variable (for
setting a default archive) -- that doesn't seem to have been sorely
missed.


    > I'm frequently in the position in which I'm in one role on one
    > tty, and another role on another tty. I'll frequently do work on
    > one tty, get tired of the problem, and move to the other tty and
    > pick up my work there.

    > Basically, my roles are tty based.  I like the idea of being
    > able to on tty1 say "export ARCH_HAT=hacker" and on tty2 say
    > "export ARCH_HAT=drone".  That way, my-ids are set, my default
    > archive is right, so forth and so on.


Roughly speaking, you're using ttys plus your window manager plus your
shell as a kind of "context manager" where, within each context, at
least some of parameters to commonly used programs (e.g., hypothetically,
--hat to arch) are held quasi-constant: you mostly just want to
set-and-forget them, perhaps sometimes you want to change the
parameter settings on a particular tty.

There are lots of ways to do that that don't involve adding
environment variable sensitivity to arch itself.   You could simply 
wrap arch:

        tla --hat $HAT "$@"

or you could do something fancier.   For example, how about a 
command like:

        % tla with-constant-params [params] > xtla
        % chmod u+x xtla

as in:

        % tla with-constant-params --hat hacker > xtla
        % chmod u+x xtla

        % ./xtla my-hat
        hacker

That might prove to more flexible, anyway.

You can still use the environment just by calling "xtla" "tla",
storing different copies in different directories, then changing the
$PATH in each tty rather than $ARCH_anything.

The point is, those alternative solutions give you lots of ways to
control "hidden parameters" to arch without, at the same time,
requiring everyone else to keep control of those hidden parameters.


    > The problem that we're trying to solve with roles doesn't really
    > get solved if every time I switch ttys, I have to remember to
    > type tla my-hat.

We need some good context management facilities in there, yes.
$ARCH_something Environment variables, traditional though they may be,
are hopefully not what's really needed.

    > If you ask me, not supporting an env variable does the exact
    > opposite of what you intend, by removing the ability to set a
    > local context and forcing a global one.

I think you're not considering other other ways to create contexts, is
all.


    > On an unrelated note, here's a troll: s-exps are ugly, Ugly, UGLY.
    > They're wrong, man! 

A serious answer though:

There is a long though somewhat obscure tradition of extending s-exp
readers and writers with customizations for particular data structures
so that you don't always have to use, for example, so many parens.

I don't see why we can't eventually do the same thing although I'd
place it as a low priority at the moment.


    >>> bugs:
    >>>   I don't think we'd have a problem here. [whith $ARCH_stuff] 
    >>>   Sure, if tla didn't
    >>>   provide library support to look up the my-idish stuff, or if tla
    >>>   was not using it consistantly, I'd agree. But tla does use the library
    >>>   routines consistantly, so we don't need to worry about either bugs or
    >>>   flakiness (a subset of bugs)

I see it more as small part of an inevitable class of bugs if we go
down the slippery slope of environment foo in an unprincipled way.


-t