-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove --directory
option for cylc install
#4823
Conversation
Also improve help descriptions of options
Merge behaviour into renamed arg WORKFLOW_NAME -> SOURCE
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👍
''', | ||
re.VERBOSE | ||
) | ||
"""Matches relative paths that are explicit (starts with ./)""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, is this path format officially called "explicit relative"? If you invented the term, I quite like it 👍 Although arguably it's really an absolute path that goes through $PWD.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't seem to find any terminology for relative paths for differentiating between whether they start with ./
or not. Explicit and implicit seems to be something one of us (maybe Tim, as author of the issue #4676) came up with.
Maybe we should avoid calling relative paths that don't start with ./
as relative paths at all; maybe calling them workflow source names would be less confusing? The arg could then be SOURCE_NAME | PATH
where PATH
can be relative or absolute but must start with ./
if relative.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The trouble is that conflicts with standard unix terminology, where a relative path doesn't have to start with ./
.
IMO ./blah
and ../blah
should really be considered absolute paths, where .
is short for $PWD
which expands to an absolute path. Like ~/blah
is an absolute path even though it is relative to $HOME
. But, that doesn't seem to be the prevailing opinion out there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you invented the term
MB but I think it's valid and helpful here.
The trouble is that conflicts with standard unix terminology
IMO ./blah and ../blah should really be considered absolute paths
I don't think that's correct, technically .
and ..
are relative paths implemented at the FS level and visible in FS listings. So .
is not short for $PWD
though it happens to resolve to the same thing.
$PWD/foo
- the$PWD
is expanded by the shell../foo
- the./
is resolved by the FS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically true, but I doubt that matters to users.
BTW I didn't mean that .
is literally short for $PWD
and, like the shell variable, expanded by the shell ... just that it is short for the present working directory. A true relative path is implicit. Presumably the main reason for the existence of ..
is to make changing up a level easier, and .
, to force the behaviour of programs that don't interpret (implicit) relative paths properly. So I'd still argue that rel/path
is a proper relative path, but ./rel/path
is kind of an absolute path masquerading as a relative path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Explicit relative and absolute paths are handled the same by the CLI so this disparity is not user facing. This is internal technical documentation in a docstring.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Which still needs to be understood at a glance by future developers).
purge_rnd_workflow | ||
|
||
|
||
exit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this exit not needed? Seems like the bulk of our tests (but not all) have it, I thought it is to ensure if an error occurs then it exits properly.
If all the bash tests are supposed to have it then I suppose we need an issue to add them to the ones that don't have it. I will wait for confirmation before opening it, it is possible some purposefully don't have it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure an exit statement with no argument at the end of a script is useless. And annoying. If no one can think of a good reason for them, let's remove them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @MetRonnie. One small query from me.
Pinging @cylc/core for any input on the unresolved reviewers' questions above |
Two approvals, and the unresolved questions above are either now resolved or don't require changes to this branch. |
@@ -86,48 +101,47 @@ | |||
def get_option_parser(): | |||
parser = COP( | |||
__doc__, comms=True, prep=True, | |||
argdoc=[('[WORKFLOW_NAME]', 'Workflow source name')] | |||
argdoc=[('[SOURCE]', 'Path to workflow source')] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
argdoc=[('[SOURCE]', 'Path to workflow source')] | |
argdoc=[('[SOURCE_DIR]', 'Path to workflow source directory')] |
''', | ||
re.VERBOSE | ||
) | ||
"""Matches relative paths that are explicit (starts with ./)""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you invented the term
MB but I think it's valid and helpful here.
The trouble is that conflicts with standard unix terminology
IMO ./blah and ../blah should really be considered absolute paths
I don't think that's correct, technically .
and ..
are relative paths implemented at the FS level and visible in FS listings. So .
is not short for $PWD
though it happens to resolve to the same thing.
$PWD/foo
- the$PWD
is expanded by the shell../foo
- the./
is resolved by the FS.
These changes close #4676 and partially address #4786
Remove
--directory
option forcylc install
and instead allow any directory in the source arg (cylc install [SOURCE]
):foo/bar
): look for source relative to each path inglobal.cylc[install]source dirs
and install first match./foo/bar
): source is relative to PWD/home/user/foo/bar
): source is at that pathRename
--flow-name
option to--workflow-name
and add-n
for short (the consensus in #4786 seemed to be--workflow-name
is preferable to--id
).Requirements check-list
CONTRIBUTING.md
and added my name as a Code Contributor.setup.cfg
andconda-environment.yml
.