showyourwork
How do we maintain older versions of showyourwork?
An update today to the tabulate package (v0.8.10 -> v0.9.0) breaks Snakemake v7.14.2 because of this line in the __eq__ method of a Rule.
https://github.com/snakemake/snakemake/issues/1892
Basically when building up the summary of the DAG, at some point tabulate checks whether an instance of a rule is equal to a certain string, which that __eq__ is not capable of handling, causing an AttributeError instead of just returning False. This happens at the beginning of the workflow so it causes everything to fail, for all builds of all showyourwork projects. I suspect it might also break previous versions of Snakemake, but I need to test that still.
It's a trivial fix on the Snakemake side -- e.g., just check if the RHS and the LHS are both of type Rule. On our end, we can fix things for the next release of showyourwork by monkeypatching Snakemake or simply pinning tabulate at v0.8.10 (that's what I had to do in #213, which upgrades the workflow to use this newer version of Snakemake).
But how do we fix already released versions of showyourwork? Workflows based on 0.3.1 and earlier will begin to fail with a cryptic AttributeError deep inside tabulate. The usual approach to this is to tell users to upgrade -- I imagine that's what Snakemake will have to do.
But our problem is more serious: our workflows are defined to work with specific versions of showyourwork (and, by extension, Snakemake), since we want things to be reproducible. But because Snakemake doesn't pin all of its dependencies at exact versions (and those dependencies don't pin their dependencies, etc.), we're running into a fundamental problem with this approach: things can break at any time, without warning, and there's nothing we can do about it other than tell users to manually bump the version of showyourwork defined in a workflow.
In my mind, the only solution is to reconsider the versioning of showyourwork workflows. Perhaps we should always build articles with the latest version and abandon the version: syntax in the config file? We'd have to be very careful about backwards compatibility (as always).
@dfm what do you think?
I suggest that we rethink our approach to versioning and get rid of the idea of a "locally installed version" and a "workflow version". We could simply decide to always build a workflow with the locally installed version. Perhaps workflows could define a minimum version and raise an error if that's not met. This is how Snakemake does it, after all.
This might be one of those "why didn't we do this in the first place?!" moments. We'll have to be very careful about backwards compatibility -- an article built with any version of showyourwork greater than the minversion must be identical in all cases.