CLI: default workflow from source dir?

[hjoliver]

User feature request:

If I'm in a source directory ~/cylc-src/foo (say), cylc install defaults to installing a new copy of foo as foo/runN.

If I'm still in ~/cylc-src/foo could cylc play and cylc stop etc. default to foo/runN too, if it exists?

This would be convenient during development, in the source directory, which typically involves a lot of repetition of cylc install then cylc play my-long-workfow-id and cylc stop my-long-workflow-id.

Trying to recall why we don't do this:

• not a deliberate decision?
• or ... starting and stopping a workflow is more consequential than installing one? (I'm not sure that's a good enough reason)
• or ... it would complicate ID parsing a bit if we allowed task IDs with an assumed workflow ID? (cylc trigger //1/model?)
• ?

[oliver-sanders]

This has been discussed, the current behaviour is as designed, it might be in a proposal somewhere?

Because installation is not a 1:1 mapping, it is not really possible to do this without things getting confusing / dangerous when multiple installations are involved.

$ cd ~/cylc-src/x
$ cylc install --workflow-name foo
$ cylc install --workflow-name bar
$ cylc play  # eh? what do you want me to do?

$ cylc ~/cylc-src/y
$ cylc install
$ sleep 1d  # come back to things later
$ cylc install -n foo
$ cylc play  # opps, I've messed with the previous installation

The mapping between an installed workflow and it's source are contained in the _cylc-install directory which is located within the run hierarchy. There is no opposite mapping from the source directory linking back to the run directory.

[oliver-sanders]

We have also discussed inferring the workflow from the run rather than source directory (which is much easier). As it happens, cylc reinstall currently does this (although we may want to change that).

[hjoliver]

Because installation is not a 1:1 mapping, it is not really possible to do this without things getting confusing / dangerous when multiple installations are involved.

That's why I said, default to [the default latest install] <source-name>/runN, if it exists.

That would be reasonable wouldn't it? i.e. if you do not specify a workflow ID and you are in a source directory, default to the default-form latest-run ID if it exists.

This would be quite an ease-of-use convenience for those using the default install locations. (Which ought to be most of us, most of the time).

[hjoliver]

But, to go further than that, perhaps we could put a latest-install symlink in source directories?

[hjoliver]

$ cd ~/cylc-src/x
$ cylc install --workflow-name foo
$ cylc install --workflow-name bar
$ cylc play  # eh? what do you want me to do?

This would simply fail, with Workflow not found: x/runN or similar.

Unless of course x was previously installed without --workflow-name, in which case it would attempt to play that one. (Which is fine, so long as you know how workflow ID is inferred if you don't specify it).

$ cylc ~/cylc-src/y
$ cylc install
$ sleep 1d  # come back to things later
$ cylc install -n foo
$ cylc play  # opps, I've messed with the previous installation

This would attempt to play y/runN, which again I think is fine. If you don't give an ID you should be aware of how it is inferred.

However, a latest-install symlink in the source directory might be even better?

[dpmatthews]

This would be convenient during development, in the source directory, which typically involves a lot of repetition of cylc install then cylc play my-long-workfow-id and cylc stop my-long-workflow-id.

#3896 will make this much easier (e.g. cylc vip --tui).

[wxtim]

@hjoliver - Do you think that we will have sig user demand for this feature? And if we do will it be for playing the latest (runN) install, or for playing "the install I meant to play" (no matter how hard that might be to deduce).

If we are being ruthless about release dates I think that it's a post 8.0 feature because it won't break anyone's working practice if we add it later.

[hjoliver]

(If we implement cylc vip etc., the pressure is off this).