Design: Aliases for Keys

[aqw]

Allow an alias for shorthand to longer keynames (such as path for onyo.path.relative). They are merely aliases, and thus technically do not reserve key space. It's rather a squatting of namespace because it translates them to another space.

Though the original idea for this came from pseudo keys (see #678 and #688), Aliases work with any key names.

When geting or seting, there is no attempt to check if the alias name exists as real data in the target assets (or anywhere). Aliases are expanded immediately, and the internals of Onyo are largely ignorant of them.

It will be the responsibility of fsck to do a sanity check for aliases that squat on top of existing keys (see #679 #599).

By default, Onyo repositories will be init-ed with a single default alias: path->onyo.path.relative (see #688). It is such a dominant use-case that it deserves to be the default.

Aliases should be defined via onyo configuration, so all the usual user-preference hierarchy applies (git config then onyo config).

[onyo "key-alias"]
    path = onyo.path.relative
    o.g = onyo.git

Open question:

• Can aliases use other aliases? This would be powerful, but makes lookups more complicated.
• Should onyo config onyo.key-alias.<alias> do a sanity check for squatting on top of existing keys? (see #679)
• When aliases are used in onyo get, should the header for that column use the expanded name?

[bpoldrack]

When aliases are used in onyo get, should the header for that column use the expanded name?

Not sure. I'd lean towards: Use the alias when printing a table for human consumption, expand in machine readable mode.

[aqw]

We don't print the headers in machine readable mode.

[bpoldrack]

Right. Ignore that. ;-)

So, not expanding is the answer, I think. We print what's queried. If the query uses an alias, so does the response. That's also the most straight-forward way to effectively let the user decide what to use.

However, that makes me think onyo list-keys should print aliases and what they resolve to. https://github.com/psyinfra/onyo/issues/679

[aqw]

We print what's queried. If the query uses an alias, so does the response.

I'm comfortable with that. And I think it allows for another use-case where users temporarily want a different representation (could be interesting in the context of globbing). Which is kinda cool when you think about it...

However, that makes me think onyo list-keys should print aliases and what they resolve to.

Good idea. I agree that should be listable.