You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just used these materials with a group of around 10 learners in a virtual workshop. My learners were familiar with programming and CLIs, but not necessarily Python. They were interested in HPC. It was internal to my company, and we loosely followed Carpentries practice as well as we could. We used two sessions of two hours, split by lunch. We finished on time without me feeling like we rushed anything. We did however skip the section on use in an HPC, but did comment on it, and we encouraged those interested to read the HPC section independently, and also gave links to specific materials dealing with the use of SnakeMake on an HPC with Slurm.
At the end, we asked for feedback from learners, but only got two bits of pedagogical feedback:
glob_wildcards utility was unclear, the example seemed trivial. (Perhaps an example is needed with more than one wildcard?)
The resources section was difficult to understand. (I found this difficult to teach particularly as apart from CPU cores, resources are arbitrary and can be fabricated.)
I'd also like to emphasise #83 as an annoyance, but it did help to emphasise that SnakeMake has had some annoying breaking changes to its CLI, sometimes between minor rather than major versions...
The use of --quiet in the SnakeMake CLI has also changed: it should be --quiet=all to retain prior behaviour in later versions of SnakeMake.
If using Python 3.10+, from collections should be from collections.abc. This has been noted elsewhere too.
I found it useful to include a rule for generating DAGs:
I introduced this rule at the end of the "Pattern rules" section and used it later to regenerate the DAG to assert that the workflow was still sensible. I find that including a DAG image in an archive is a noteworthy practice. It did however require covering wildcard_constraints, so I suppose that could be omitted.
Thanks a lot for the work that has gone into this.
The text was updated successfully, but these errors were encountered:
I just used these materials with a group of around 10 learners in a virtual workshop. My learners were familiar with programming and CLIs, but not necessarily Python. They were interested in HPC. It was internal to my company, and we loosely followed Carpentries practice as well as we could. We used two sessions of two hours, split by lunch. We finished on time without me feeling like we rushed anything. We did however skip the section on use in an HPC, but did comment on it, and we encouraged those interested to read the HPC section independently, and also gave links to specific materials dealing with the use of SnakeMake on an HPC with Slurm.
At the end, we asked for feedback from learners, but only got two bits of pedagogical feedback:
glob_wildcards
utility was unclear, the example seemed trivial. (Perhaps an example is needed with more than one wildcard?)I'd also like to emphasise #83 as an annoyance, but it did help to emphasise that SnakeMake has had some annoying breaking changes to its CLI, sometimes between minor rather than major versions...
The use of
--quiet
in the SnakeMake CLI has also changed: it should be--quiet=all
to retain prior behaviour in later versions of SnakeMake.If using Python 3.10+,
from collections
should befrom collections.abc
. This has been noted elsewhere too.I found it useful to include a rule for generating DAGs:
I introduced this rule at the end of the "Pattern rules" section and used it later to regenerate the DAG to assert that the workflow was still sensible. I find that including a DAG image in an archive is a noteworthy practice. It did however require covering
wildcard_constraints
, so I suppose that could be omitted.Thanks a lot for the work that has gone into this.
The text was updated successfully, but these errors were encountered: