Add Snakemake report

• add/update packages in conda environments (snakemake 5.19.2)
• add basic snakemake report command call
• turn off labkey-related CI test

changed milestone to %v0.2.0 release

mentioned in issue #127 (closed)

assigned to @gypas

added Blocked label

@bakma I'm afraid you will need to merge in the changes from the last 10 commits before we can merge :-S

That's unfair - I have had this done and the merge request was filed 6 days ago. It's not my fault it was not taken care of. And now you tell me that there are some recent changes and I had to solve conflicts? No, not cool.
On top of that, I still don't know what exactly would you like to change here. What was the decision on the wrapper? Where did you, @katsanto and @gypas decided to eventually parse information?

I'm sorry about this, but I just didn't see it earlier. From my side it could have been merged with the tests commented out, just like it was done for Foivos' PR (and I suppose Dominik's and Maria's). But these things happen sometimes. What do you suppose to do about it? The conflicts are there and have to be resolved.

My proposal is that you merge dev into this feature branch, look at the conflicts and push again. I would just do it myself instead of writing messages here back and forth (it really only takes 10 min), but as I said, I don't understand this issue/PR, so the chance that I mess sth up is much higher because I neither wrote the original code NOR most of the code in the commits that were merged in the meantime. As for you: you can just always accept "theirs" unless it's code that was changed by BOTH sides, in which case (if there's a case like that at all) you have the best idea on how to keep both the new changes while still making them work in the way you intended them to work. I understand that you feel that it's unfair (I guess it is a bit), but in my opinion it's still the safest way, and it's really not that big of a deal. And if it DOES take you longer than 10 min, then I think it's worth the exercise.

About the changes/wrapper: Is this about adding something to config.yaml and/or generating a Bash script for running Snakemake? I'm not too well aware what's behind all that, but I'm pretty sure the final call was to add it to scripts/prepare_inputs.py where similar issues are already taken care of. But I'm not sure how this relates to this PR? Should this go in here?

Do me a favor @bakma and click on the "Resolve conflicts" button!

assigned to @kanitz and unassigned @gypas

unassigned @kanitz

@gypas Sorry, but I don't know which code was added to this commit, and with what reasoning, so I'm not in the best position to resolve conflicts

I checked the conflicts and they are not that major (just 2 lines of code), so I can resolve them if you don't want to @bakma

added 11 commits

• 6efbc289...196941bf - 10 commits from branch dev
• 51a38f70 - Merge branch 'dev' into 'SnakemakeReport'

Compare with previous version

Thanks a lot @bakma! And thanks to Git for being so smart. So what's the plan @bakma - we merge this after the test completes? Or does this need some changes still (config/wraper)?

IMO, it should be merged now.
The wrapper is a structural change, not affecting the functionality/shape of the report and if we want that change it should be a separate issue. Please merge before I get scooped again :>

assigned to @gypas

Haha, sure!

merged

mentioned in commit 1aa8e146

I will have a look at it now. Does it generate the reports in the root at the moment?

No, not at the root. Please take a look at the test.local.sh under integration tests.
At first the scripts cd's into the a proper directory and then later - it creates the report there, in the cwd.

In a sense: a path for for the report is hardcoded for the commands in the same way as the path to the Snakefile.

Ah ok already merged. Fine then.

Sorry :-)

It's fine. Let's leave it like this now and let's open new issues if we encounter problems.