cylc-flow icon indicating copy to clipboard operation
cylc-flow copied to clipboard

CLI: default workflow from source dir?

Open hjoliver opened this issue 2 years ago • 8 comments

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?)
  • ?

hjoliver avatar Jun 23 '22 11:06 hjoliver

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 avatar Jun 23 '22 14:06 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).

oliver-sanders avatar Jun 23 '22 15:06 oliver-sanders

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 avatar Jun 24 '22 00:06 hjoliver

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

hjoliver avatar Jun 24 '22 00:06 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?

hjoliver avatar Jun 24 '22 01:06 hjoliver

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).

dpmatthews avatar Jun 27 '22 07:06 dpmatthews

@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.

wxtim avatar Jun 27 '22 10:06 wxtim

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

hjoliver avatar Jul 05 '22 08:07 hjoliver