Ivan Ruiz Manuel comments

Results 163 comments of


                                            Ivan Ruiz Manuel

`ancient()` statements are arbitrarily ignored when using a workflow as a `module:`

@Hocnonsense would this make it so that `ancient` never works for cloned repos, then? Then it would be (imo) a bug, since ancient is meant to protect your input files...

`ancient()` statements are arbitrarily ignored when using a workflow as a `module:`

@Hocnonsense to prevent changes from impacting the debugging of this issue, I created a tag https://github.com/calliope-project/module_hydropower/tree/snakemake-ancient-issue I'll try to see if specifying `ancient` via the CLI results in the same...

`ancient()` statements are arbitrarily ignored when using a workflow as a `module:`

@Hocnonsense I'll soon have to merge the branch where this issue was found (with a workaround to get around the problem). It might take a while for this issue to...

`ancient()` statements are arbitrarily ignored when using a workflow as a `module:`

Just to report that this is still seen in v9.9.0. Unfortunately it's making the use of `ancient` impossible in our workflows, since it often has the opposite effect.

`ancient()` statements are arbitrarily ignored when using a workflow as a `module:`

will do!

`ancient()` statements are arbitrarily ignored when using a workflow as a `module:`

@Hocnonsense after some testing with the latest version, the issue seems to be gone! It's a bit tricky to reproduce, but unless I see it again, let's consider this one...

Easily define group constraints with custom math

Pitching in here: I really like approach number 4. It's very intuitive. As for the `default_if_empty`: I think we should arrive to a style that makes it explicit that using...

Easily define group constraints with custom math

Thanks Bryn! I also prefer option 2. Some comments, though: - I think there is a bit too much repetition going on due to specifying `cap_node_groups` every time. - Setting...

False-positive: `pdb` returns false 'NameError' exception for variables in list comprehension

Had to update the issue, turns out this is way more general than I initially though. I hope this is fixed soon, this makes debugging quite hard

Lines without curly brackets in triple-quoted f-strings vanish

Seeing something similar in https://github.com/snakemake/snakemake/issues/3018 It seems like broken in the steps that pass snakemake text to the python interpreter, modifying strings everywhere...