-
Notifications
You must be signed in to change notification settings - Fork 717
Fix GString equality checks with String #6330
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
base: master
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for nextflow-docs-staging ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
f4db36e
to
b12e2d2
Compare
ab74df5
to
2041fcf
Compare
Signed-off-by: Ben Sherman <[email protected]>
2041fcf
to
7c040c7
Compare
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.
A couple of non-blocking suggestions. Please check meaning is retained.
Nextflow will evaluate this directive dynamically if it references task inputs. Directives that use an explicit closure are still resolved dynamically. | ||
|
||
:::{note} | ||
Process configuration options must still be specified with a closure in order to be dynamic. |
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.
Process configuration options must still be specified with a closure in order to be dynamic. | |
Process configuration options must be specified with a closure to be dynamic. |
:::{versionadded} 25.10 | ||
::: | ||
|
||
Dynamic directives do not need to be wrapped in a closure when using the {ref}`strict syntax <strict-syntax-page>`: |
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.
Dynamic directives do not need to be wrapped in a closure when using the {ref}`strict syntax <strict-syntax-page>`: | |
Dynamic directives do not need to be wrapped in closures when using the {ref}`strict syntax <strict-syntax-page>`: |
Treating Dynamic directives as plural
``` | ||
|
||
Note, however, that the latter syntax can be used both for a directive's main argument (as in the above example) and for a directive's optional named attributes, whereas the closure syntax is only resolved dynamically for a directive's main argument. | ||
Nextflow will evaluate this directive dynamically if it references task inputs. Directives that use an explicit closure are still resolved dynamically. |
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.
Nextflow will evaluate this directive dynamically if it references task inputs. Directives that use an explicit closure are still resolved dynamically. | |
Nextflow will evaluate directives dynamically if they reference task inputs. Directives that use an explicit closure are still resolved dynamically. |
This PR improves the semantics of GStrings and lazy expressions in the strict syntax.
GStrings are coerced into Strings by appending
.toString()
under the hood, so that equality checks like"${'test'}" == 'test'
are correct.Lazy expressions in process inputs/outputs/directives are handled more consistently. Before, only GStrings and property expressions were lazily evaluated. Now, any expression that references a variable is wrapped in a closure.