Re: [Gnu-arch-users] version aliases

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > Tom Lord wrote:
    > > Is this something you want to code up or just an idle thought?

    > > I.e., is it worth explaining how to go about implementing it?

    > Well, I've put it into aba, and it's been quite handy.  Putting it into 
    > tla proper would probably entail getting most commands to use new 
    > functions for picking revisions.

Not really.   Aliases would need a distinctive syntax -- perhaps a
prefix character.   So, you wouldn't say:

        tla get latest-emacs

you might say:

        tla get :latest-emacs

All commands use arch_valid_package_name and friends to check
arguments for validity -- these could be modified to look up (and
memoize lookups of) alias names.  (The validity of aliases should be
conditional.   For example, internally, most calls will not want to
permit aliases;   in cmd-*.c, aliases should usually be permitted.

For the most part, a command-line argument goes through
arch_parse_package_name before it's used as an argument to internal
functions.  That would do the alias->real-name translation.  (Again,
conditionally.)

It's _possible_ that there are some places where command line
arguments are used directly rather than via arch_parse_package_name.   
There are 96 cmd-*.c files to review for that.   That wouldn't take
too long.

The hard part is designing how archive-wide (for all users of a
certain archive),  meta-archive (archives containing aliases referring
to other archives), and per-user aliases are stored, what they consist
of, which take priority, where to search for a given name, etc.  

This is the part that would take the most work, again, mostly in those
96 cmd-*.c files.   For example, suppose that we have per-archive
aliases.  Well, in which archive should tla search for the meaning of:

        tla get :latest-emacs

?  arch_valid_package_name and arch_parse_package_name would need some
extra parameters.


    > In my input validation work, I've noticed that pretty well every command 
    > that accepts either a version or a revision has its own implementation 
    > of determining the revision of a version.

    > It wouldn't hurt to unify the processing by providing an 
    > "arch_determine_revision ()" command in cmdutils that validated the 
    > version/revision, checked if the supplied version/revision existed, and 
    > determined the latest revision if the version was supplied.

    > That way, there's always decent input validation, and less duplicate 
    > code.  Maybe we could add alias expansion there.  Maybe we could make 
    > patchlevels always refer to the tree-version at the same time.

Sure.   The code duplication in a few places is bogus.... in other
places I recall there being subtleties that made one commands argument
interpretation slightly different from another's for good reasons
but....

One plan would be:

1) design the alias mechanism
2) implement the internal support for it
3) prioritize the cmd-*.c files
4) pick off cmd-*.c files incrementally until done, perhaps
   factoring out some of the argument parsing code at the same
   time

-t