-
Notifications
You must be signed in to change notification settings - Fork 22
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
Move some properties into resources #2
Comments
I've moved all the various scheduler specific properties into the resources directive and got rid of the workdir for the moment. The only issue here is that resources only allow integers. This forces the user to set the walltime in seconds rather than using a string in the HH:MM:SS format. The second, and more annoying, issue is the memory can now only be allocated in bytes. I would prefer to set the memory request as a string using '1mb' or '1gb' etc. Is there a particular reason why strings are not valid in the resources directive? |
It is advisable to annotate resources with the unit, e.g. There is no established standard yet, but I would propose the following resources to be considered:
|
Thinking about it, it might be indeed a good idea to additionally support strings, and parse them with the humanfriendly python module. This way, we could easily achieve what you have in mind for sizes and times. |
Then, we could allow things like |
Hi, I came across this searching for a feature to set N.B. is there a specific reason that |
Yes, this is stll planned. I hope to be able to work on this soon. Threads being separate is mainly for historical reasons, but also because it is the only resource that cannot be learned from previous runs. In the future, snakemake will learn the other resources from runs with previous samples, such that they just can be annotated in order to provide a prior guess. |
Quick update for any that finds this Issue. Snakemake supports strings as resources as of version 5.15.0 released on 2020-04-21 (changelog) |
Some of the properties (like wallclock time or memory) would rather belong into the resources directive.
Some are redundant and encourage people to put stuff in the wrong place. E.g., I would not consider threads that are set within params instead of via the threads directive. Otherwise such a workflow would be not portable to different profiles or simply plain local execution anymore.
The workdir handling is also very custom and not portable.
The text was updated successfully, but these errors were encountered: