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

[David Allouche]

General question, who the "we" you are using in your whole email is
referring to?

[Mangling order of citation a bit]

James Blackwell wrote:
> Tom Lord wrote:
> >   ~ add support for multiple identities
> >
> >     You should be able to have multiple arch user ids.
> >     You should be able to set various parameters (e.g.
> >     your archive registrations) based on which of your
> >     user ids you are using.
> 
> 1. I really like the role based setup, in which there's a (still human
> readable) .arch-params equivilant. However, rather than tying the role
> to the my-id, I think we should have "role names" instead. These names
> would fit the format of [a-zA-Z0-0_-]+. For example, valid role names
> would be "arch", "archdev", "canonical" and "default". When a new user
> is set up for the first time, put them in the "default" role. We want
> this change because it shortens what users have to type. We don't have
> to worry about namespace changes because I think these role names should
> be local.

== Explicit roles / Context sensitivity ==

Role-based set up is a good idea, but I believe that most (or all) of
the use cases can be better addressed using context sensitivity.

The role-switching model makes it necessary to explicitely switch
roles when switch projects. It does not address the "commit with id IX
on archive AX and id IY on archive AY" that the proposed per-archive
user-id patch addresses.

Contrast:

  ### Explicit roles
  cd ~/mystuff/www
  tla role private
  commit -s 'hack my home page'
  cd ~/work/bizplan
  tla role work
  commit -s 'bucks out of ducks'

  ### Context sensitivity
  cd ~/mystuff/www
  commit -s 'hack my home page' # right user id for private archive
  cd ~/work/bizplan
  commit -s 'bucks out of ducks' # right user id for company work

The former has exactly the same oops factor as the current situation,
the latter is much more easy and foolish-overworked-hacker-proof.

The right context to depend on should be along the lines of "the
version we are operating on". It could default to the tree-version,
but in the same way as "commit" defaults to the tree-version.

In addition, it is useful and more elegant to have a concurrency-safe
kind of context so different tool (scripts, cron jobs) can run
concurrently without having to hack $HOME. The "explicit context"
solution falls short of that requirement by setting global state in
~/.arch-params.

== Per-role/context archive registrations ==

I believe that per-role archive registration is the wrong solution to
a number of assorted use cases. As far I can tell, it's only purpose
is to shorten the output of "tla archives", however I think that most
of the time you should not have to use that command in the first
place.

Some uses cases jblack has described me which current involve using
"tla archives":

  get -- That one is a catch-all. There are many use cases for get.
  
    1. Get a newly registered archive: you already have the archive
         under you fingertips. No need for "tla archives".

    2, 3, ... what other common use cases around?

  whereis -- Tell the location of an archive to another user.

    1. Random archive we happen to have registered

       Here, some searching ability in "tla whereis-archive" or "tla
       archives" will probably address the use case more effectively 

    2. Well known archive related to something we are doing

       This can be solved as efficiently as with roles using context
       sensitivity. "tla archives --context" or something.

   Custom mirrors -- Push-mirror to two or more places.

     That use case is entirely addressed by the "cleanup archive
     registration" feature.

Finally, _literal_ per-role archive registrations are ugly because
archives are global objects. An archive can only be registered under
one name (modulo mirrors), and it is a global name.

What you probably want instead is contextual restriction of the output
of some commands to only parts of the Arch namespace.

> >   ~ clean up archive and mirror registration
> >
> >     The little hack of naming archives with "-MIRROR" or
> >     "-SOURCE" is fundamentally lame.
> >
> >     We plan to clean up the database of registered archives
> >     so that you can have one record that lists all the locations
> >     for a given archive and enumerates the mirroring relationships
> >     among them.   

Fantastic!

> >     Related to that, we'll add some stuff so you can configure
> >     mirroring rules and have the rest be automated: For example,
> >     statically remember that a mirror should be "pulled on demand"
> >     or "pushed after commit".    The ~/.arch-params database will 
> >     be expanded to allow such policies to be recorded.

That needs more discussion to get right. One requirement that pops
immediately into my mind is the ability to switch between online and
offline modes.

> >   ~ add archive aliases
> >
> >     Yes, we'll add short-names for archives.
> >
> >     Think how nicely this works out in combination with multiple
> >     identities:  we can make the short-names for archives
> >     identity-specific.  
>
> 2. re archive aliases. Nah. I think we should have fully qualified
> aliases. I.E. jbdev expands to address@hidden/tla--devo--1.2, 
> tomtla expands to address@hidden/tla--devo, so forth and so on.

It seems you are both agreeing on that.

Modulo the caveat that "explicit roles" is in my opinion the wrong way
to do it, I'll all in favor of it.

Binding aliases to user-ids seems wrong to me. You should not need
different user ids (global, archived datum) to used different sets of
aliases (local, transient behaviour).

> >   ~ transactionalize ~/.arch-params
> 
> The rest of it, I think I like it as is, though I'm a little nervous on
> he transactualizinaterating .arch-params, particularly when it comes to
> merging hooks.

That sounds intriguing to me. That would certainly make wide deployements
considerably easier.

> >   ~ 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).

Also, having to add an explicit option for using another params
directory might be a bit heavyweight for some people. 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.

-- 
                                                            -- ddaa