New Feature: `onyo.` namespace for Pseudo Keys

[aqw]

All Pseudo Keys, now and in the future, should live under the onyo. namespace. See #678 for design background.

New Structure:

• onyo.is.asset: True or False
• onyo.is.directory: True or False
• onyo.path.relative: path relative to repo root (currently what path is)
• onyo.path.parent: parent directory (currently what directory is)
• onyo.path.file: full path relative to repo root (relevant for asset directories and templates)

Retired:

• directory (now onyo.path.parent)
• path (now onyo.path.relative)
• template

  • 692 is not a blocker for this issue, and template can be skipped or removed entirely, whatever is easier

• is_asset_directory

Note:

• All pseudo keys are queryable. Ideally they always have a value (True/False, etc). If they are truly irrelevant/impossible, then <unset> is the appropriate value.
• Asset Directories (will return True for both is.asset and is.directory).
• The concept of "reserved keys" should likely be retired.
• There is a possibility that some pseudo keys will become setable (perhaps onyo.path.parent (i.e. mv) and onyo.is.directory (i.e. mkdir/rmdir))

Future (out of scope for this issue; just context):

• 662 will live under onyo.git

• 675 will add onyo.is.template: True or False

• 674 will add onyo.is.empty: True or False (only ever True for directories and possibly templates)

• 692 will add onyo.config.*

[aqw]

While writing this, it became apparent that we overlooked onyo.template in the design phase. It is very clearly the odd one out. It has no value beyond onyo new, and could never be queryable.

What about something like onyo.new.template (or onyo.new.--template or...). Or maybe onyo.cli.--template (and make `onyo.cli. a generic namespace to call flags)?

Ideas are most welcome here.

[aqw]

I have created #692 to allow onyo new to temporarily override onyo configuration key values. That solves the onyo.template problem.

[bpoldrack]

I like this approach. Want to throw in one more thing, though: onyo.is.template. This isn't actually related to the template "key" you mentioned above, but to #675.

[aqw]

Yup! This issue I intentionally omits keys for new features. There is an onyo.is.template in #675

[bpoldrack]

Generally, I do support the idea of onyo.cli.template. I wouldn't put in the --, though. While it's a reference to a command option, the weirdness of onyo.cli.--template isn't necessary and furthermore: There is a difference in behavior. Such keys would be meant to specify per-asset options. Which is different from the switch itself, which refers to the entire command.