Make a new standard template variable "CYLC_SOURCE_DIRECTORY"

[wxtim]

available to users.

Closes #6830

Check List

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Applied any dependency changes to both setup.cfg (and conda-environment.yml if present).
• Tests are included (or explain why tests are not needed).
• Changelog entry included if this is a change that can affect users
• Cylc-Doc pull request opened if required at Added CYLC_SOURCE_DIRECTORY template variable to jinja2 doc cylc-doc#868.
• If this is a bug fix, PR should be raised against the relevant ?.?.x branch.

[hjoliver]

(I'm sure you were about to do the var name changes, sorry!)

For completeness, should this be added as a job environment variable too?

(Probably NO - we don't want jobs to mess with source dirs, as a matter of principle - but other template vars are also job vars(?), and maybe a valid use case could be conjured up...)

[wxtim]

For completeness, should this be added as a job environment variable too?

For

• Other template vars are also job vars(?) - not true - CYLC_VERSION is provided, but not CYLC_TEMPLATE_VARS.

Against

• We don't want jobs to mess with source dirs, as a matter of principle - Somewhat defeats the point of having
• maybe a valid use case could be conjured up... - We haven't got a use case and can't come up with one readily - if we add it and someone finds a use case this is the sort of thing that creates maintainance headaches.

So I'm going to say no.

[oliver-sanders]

For completeness, should this be added as a job environment variable too?

Nooooo!

We definitely shouldn't be encouraging workflow writers to make use of resources in the workflow src dir.

Note, we already decided this which is why we removed the CYLC_SUITE_DEF_PATH variable!

Exposing the source dir at all is annoying, but I have been convinced that this is necessary for rose-stem type use cases.

[hjoliver]

Nooooo!

🤣 - well that's why I said "probably NO", just checking.

[hjoliver]

@wxtim - you have resolved the first two of my suggestions without applying them. If that was deliberate, I'll argue the point: They're not functional code but should use the actual variable name CYLC_WORKFLOW_SRC_DIR or normal text, e.g. "workflow source directory". Currently they use two different capitalized names: WORKFLOW_SOURCE_DIRECTORY (change log); and CYLC_SOURCE_DIRECTORY (in-code comment).

[wxtim]

@wxtim - you have resolved the first two of my suggestions without applying them. If that was deliberate, I'll argue the point: They're not functional code but should use the actual variable name CYLC_WORKFLOW_SRC_DIR or normal text, e.g. "workflow source directory". Currently they use two different capitalized names: WORKFLOW_SOURCE_DIRECTORY (change log); and CYLC_SOURCE_DIRECTORY (in-code comment).

Not intentional - Either some sort of regression of failure of mine making the changes locally, or GH having some sort of brain fart and not applying changes I asked it to.

[oliver-sanders]

I'm not sure we need to run the workflow for this test?

Suggested change

	cylc vip \
	--pause \
	--no-run-name \
	--workflow-name "${WORKFLOW_NAME}"
	cylc install \
	--no-run-name \
	--workflow-name "${WORKFLOW_NAME}"

[wxtim]

Subsequent test requires the flow-processed.cylc to check that the new variable is available and correct. As far as I can tell, template variables provided by Cylc (as opposed to those stored by rose-suite-cylc-install.conf) are not stored on installation.

[oliver-sanders]

Would be good to add a cylc view -p test here (works when I try it manually) to make sure this variable is provided in that context too (note config parsing doesn't happen here so it's a likely breakage).

Would be something like:

run_ok ... cylc view -p
grep_ok ... "${TEST_NAME}.stdout"

[oliver-sanders]

👍