Re: [Gnu-arch-users] feature plans from over here....

[David Allouche]

On Wed, Aug 18, 2004 at 10:11:57AM -0700, Tom Lord wrote:
>     > From: David Allouche <address@hidden>
> 
>     > General question, who the "we" you are using in your whole
>     > email is referring to?
> 
> Who me?  I'm a little slippery on my use of "we", sometimes meaning
> "the arch community as a whole" and sometimes meaning (in this
> context) "some people with whom I'm working off-list on arch
> features".   Hopefully context makes it clear what I mean.

You sounds like you are not able to disclose any more. Fair enough.

> Similarly to the way that "default archive", once just something you
> set in ~/.arch-params, is nowadays (from _some_ commands) something
> that can be inferred from the project tree of the current directory.
> 
> In other words, yes, you're right --- but the functionality you are
> looking for is something to build on top of what we are laying down as
> foundation right now.
> 
> (Your use scenario and analysis of the "oops" factor are good.... but 
> nobody is disagreeing with that.)

Great. I had the impression that you were thinking about going for an
"explicit role" solution at the exclusion of a "contextual role".

[elaborate discussions of things you can do with roles]

That sounds good, but these are issue I have thought a lot about, so
I'll let other people yell.

I am happy as long as:

  1. Roles are not tied to unique user ids

  2. Archives do not have to be registered multiple times for different
    roles.

  3. Roles can be assigned to subsets of the namespace, and be used
    automatically.

  4. Subsets of namespace can be defined by pattern matching.
    for example */pyarch--* will match any pyarch branch anywhere,
    where aliases such as "release", "public", "rocketfuel",
    "personal" all make sense as important partner versions.

  5. There is a mechanism for reuse. For example roles applying to
    overlapping subset of the namespace could be reconciled using a
    precedence order specified explicitly.

Apparently, the 3 last points are part of "not just now, yes as
extension". That's all right, as long as the underlying design is
friendly to such developments.

Note: point (4) will tell you something about why I think archive
registration must not be done multiple times. Wether I am wearing my
pyarch maintainer hat or wearing my employee hat, I still want to
access both my private and work archives because they both contain
pyarch branches.

>     > > >   ~ allow other directories
>     > > >
>     > > >     Of course, the well known thing we need ---
>     > > >
>     > > >     % tla --params DIR
>     > > >
>     > > >     to use DIR instead of ~/.arch-params
> 
>     > Actually, once you get around the initial repulsion, hacking $HOME is
>     > quite simple, effective and unavoidable to some extent. For example, I
>     > will not make the pyarch test suite rely on the correct handling of
>     > --params. We have recentley seen a regression in the support of
>     > "update --dir" so a regression in --params does not seem impossible).
> 
> The problem is that tweaking $HOME effects other subsystems as well.
> E.g., is it really certain that you want all of your hook scripts
> invoked by tla to use the altered $HOME?   

I think that could make sense. After all the "special arch-params"
enviroment is for very special purpose uses and it would make sense to
have it use an entirely different set of ~/bin script, gpg keyring,
ssh config, whatever.

But I can also see that you may want to use the same $HOME for
everything.


>     > I suggest the
>     > params directory be specified, by order of priority, by:
>     > 
>     >   1. --params option (absolute path)
>     > 
>     >   2. ARCH_PARAMS environment variable (absolute path)
>     > 
>     >   3. $HOME/.arch-params
>     > 
>     > Since that feature is only useful for scripts and wrappers, always
>     > requiring absolute paths should not be a burden (just use a variable
>     > here) and will significantly reduce the oops factor.
> 
> Perhaps.  
> 
> Your (2) is very problematic.   Should tla unset ARCH_PARAMS before
> calling `exec()'?   Should it *set* ARCH_PARAMS?   Should hook scripts
> do either of these?   What happens with an "unintended recursive arch
> invocation?"

Gotcha!

What happens with "uninted recursive arch invocation" when you are
using _only_ --params? I think you will to use the custom arch-params.
However, I do not see how to pass the location of the current
arch-params to hook script if not using $ARCH_PARAMS.

In that light, tla should set ARCH_PARAMS before exec() in order to
provide a consistent environment to hooks.

> (And, anyway, "hats" should *mostly* eliminate the need for a "--params"
> option.)

"Anyway?". If it's not needed, just not implement it. If it's needed,
hat do not make doing things wrong less of a bad thing.

I think it will still be needed, at least with my understanding of
hats,

-- 
                                                            -- ddaa