At the moment, each token is hard-coded to only a certain few. Instead, have each token reference one of be's environment variables; i.e. any prefixed BE_.
For example, be defines a number of variables.
BE_PROJECT: Name of current project
BE_ITEM: Name of current item
BE_TASK: Task of current item
BE_DEVELOPMENTDIR: Absolute path to current development directory
BE_PROJECTROOT: Absolute path to current project
BE_PROJECTSROOT: Absolute path to where projects are located
BE_ACTIVE: In an active environment
BE_USER: Active[1] user
BE_SCRIPT: Path to script executed when entering a project
BE_PYTHON: Python command executed when entering a project
BE_ENTER: Whether or not the development directory was entered
BE_TEMPDIR: Path to current `be` temporary directory.
BE_ALIASDIR: Path to where `be` stores its aliases.
A token could then be a direct reference to any of these, excluding it's prefix.
BE_ITEM is referenced by {item}, and BE_PYTHON is referenced by {python}
asset: {cwd}/{user}/{item}
Providing complete backwards compatibility, and room for expansion. For example, a user could append an additional variable and use that in templates.
Goal
To add flexibility to available tokens.
At the moment, each token is hard-coded to only a certain few. Instead, have each token reference one of
be's environment variables; i.e. any prefixedBE_.For example,
bedefines a number of variables.A token could then be a direct reference to any of these, excluding it's prefix.
BE_ITEMis referenced by{item}, andBE_PYTHONis referenced by{python}Providing complete backwards compatibility, and room for expansion. For example, a user could append an additional variable and use that in templates.