flow warns that executable is not used in template script

[vyasr]

Description

Submitting an operation with the executable directives set results in a warning:

WARNING:flow.project:Some of the keys provided as part of the directives were not used by the template script, including: executable

However, the script is correctly rendered with the provided executable.

To reproduce

Create an operation decorated with @flow.directives(executable=sys.python)

This problem arises because, unlike most other directives, the executable is parsed directly in Python code when operations are registered by accessing the function directives (before the JobOperation is constructed).

There are two possible solutions to this problem. The simpler solution would be to manually exclude the executable (and any other such directives) from the tracking. A more comprehensive solution would involve refactoring of the code to ensure that commands are only generated in one place. However, the second solution is probably best implemented only after groups are completed.

[csadorf]

I'd suggest to hold of tackling this until #114 is merged.

[vyasr]

@b-butler offhand, do you know how this would work with groups merged? Now that the entrypoint holds the information about the executable, is there a natural place there to handle this refactoring, or should we just skip checking this directive in tracking?

[b-butler]

@vyasr We now also have other directives that are not being used potentially. We always set ngpu, nranks, omp_num_threads, and np are set for every submission JobOperation. This is done to facilitate the aggregation of operation directives from within a group. This does make many more directives potentially unused. For instance even though nranks and omp_num_threads are set for every submission operation we only use them in particular templates (for resource requests).

For these we could do a check and use __delitem__ when they are set to zero.

With respect to the problem of executable. I think whitelisting executable makes the most sense for now. It is only used for run commands.

Looking at this issue again has reminded me that JobOperation has much of the logic in FlowGroup's different methods of creating JobOperations. This should also be refactored. I will create a separate issue for that.