It would be nice to be able to have the dot character (.) in task names and/or parameters.
My use case is to use Cylc to build and run multiple versions of a model. E.g.I want to build multiple versions X.Y of a piece of software. The natural thing to do would be to use parameters on the version strings of the piece of software, so I can have tasks called build_software_x.y, build_software_x.z and so on, and then simply feed the version string from the parameters to the build scripts.
This is currently not possible due to the dot character between used as a delimiter between task name and cycle point in task ID. Any ideas of making this possible would be welcomed.
Yes, would mean not using . as a delimiter in CLI args (so a breaking change, although / is still available)… What do people think? Cylc 8 is meant to be compatible with 7, but this may not actually effect running suites…
I would imagine this to be quite difficult, given potential usage of CYLC_TASK_ID environment variable?
My current approach is to add a Jinja2 filter that does a bit more than the standard urlencode filter so . becomes %2E and / becomes %2F, etc.
Unfortunately, I have just found out that there is a bug in Cylc when submitting jobs with the % character to SLURM with sbatch --output and sbatch --error expecting % to be a template string character, which needs to be escaped with %%.
I would reserve the dot for something like namespacing of nested sub-suites or unifying task parameters and cycle points. Special characters are precious for syntax.
For your use case, you could do something like this: build_software<version> with version = x_y and in the script BUILD_VERSION=${CYLC_TASK_PARAM_version//_/.}
I understand. The underscore _ is equally precious though. My current invention is to turn . into @point and / into @slash - the syntax is easy to parse and unparse.
Sounds like we’ve collectively decided this isn’t entirely desirable in spite of @matthewrmshin’s use case? But Matt, feel free to post an issue on GitHub if you disagree, or have ideas on how to support it without breaking the existing system…
I still think that this is worthwhile (as the use case presents a natural way of working). Thinking about it again, it may even be possible, as long as the logic is careful when extracting task name and cycle point strings from the task ID. (E.g. If we can assume that a cycle point string never has a dot in it, then this should be possible.)
I support this idea of allowing the dot character in task names and parameters. Recently I worked on a suite processing a set of files with a dot in the filename. Separating tasks for the individual files would have been easier if the dot would be possible in parameterised tasks.
Unless I’m mistaken, although the corresponding Github issue was closed in 2020, this is still unfortunately not possible in parameters.
As others in this thread before, I find it a pretty useful feature, so I’ve bumped the issue to be reopened, and I’m also reviving this thread to see if any technical hurdles/expectations have evolved since last time this was discussed.
