Remove unnecessary files in results directory

• use of temp() statements in snakemake rules
  • extract_transcriptome
  • concatenate_transcriptome_and_genome
  • extract_transcripts_as_bed12
  • calculate_TIN_scores
  • star_rpm
  • rename_star_rpm_for_alfa
  • alfa_qc
  • sort_bed_4_big
  • pe_remove_adapters_cutadapt
  • pe_remove_polya_cutadapt
  • remove_adapters_cutadapt
  • remove_polya_cutadapt
• use of --notemp in test scripts (local and slurm) for successful execution without removing temp files
  • test_alfa
  • test_create_dag_image
  • test_create_rule_graph
  • test_integration_worklow
  • test_integration_workflow_multiple_lanes
• use of shadow directive in rules
  • star_rpm
  • pe_map_genome_star
  • pe_quantification_salmon
  • pe_genome_quantification_kallisto
  • map_genome_star
  • quantification_salmon
  • genome_quantification_kallisto
• See comment in #137 (closed) for setting an optional shadow prefix, especially useful in cluster execution
• See comment in #137 (closed) for impact of disk space savings on a real-world dataset
• correctly add snakemake {threads} in execution in rules
  • fastqc
  • quantification_kallisto

Closes #137 (closed).

changed milestone to %pipeline

@burri0000 Do you mind if we merge first the changes from @bakma in (!79 (merged)) because it will be a bit more complicated to resolve issues in the other branch, rather than here? (I know that you opened first the pull request).

Isn't it easier to merge the simpler branch first? And then put the other on top? Otherwise it would be complicated to resolve the complicated branch to dev and then the easy branch to new dev, which got complicated.

Not in this case, because some of the rules from the other branch are just removed. So in a sense, it will be easier for you to do it (I don't think it will be much more than pulling and editing a couple of lines). If it will become too complicated I will help you.

Well, if you think so okay, I guess.

I'm just puzzled that first the approach on handling merge requests was "first come, first serve" but now "complicated, then simple".

Yes, sure. It's still "first come, first serve". You are just doing us a favor here :)

sounds more like: "The exception that proves the rule" xD

@burri0000 Can you please pull dev and adjust the changes. Then we can merge.

Done. After discussion today, I also reverted changes that are wrong (using -n as threads in TIN score calculation) or risky (using rm -rv command).

added Blocked label

added 3 commits

• bc168805...736d1a3d - 2 commits from branch dev
• c2ed5f3d - Merge branch 'dev' into results_dir

Compare with previous version

marked this merge request as draft

changed the description

added 2 commits

• f01989ee - remove statement of manual deletion of index directories
• f2169659 - revert parameter usage -n as threads statement in rule calculate_TIN_scores

Compare with previous version

marked this merge request as ready

removed Blocked label

@burri0000 In general it looks good to me. The only thing I don't get is why do we need to specify an absolute path here.

same here

and here

and here

and here

and here

approved this merge request

merged

mentioned in issue #137 (closed)