Add formatting env and script

[hoferand]

After merging add the following to the wiki:

• Follow Best Practices
  • Follow the official best practices guidelines.
  • For code formatting use:
    • Snakemake: snakefmt
    • Markdown/YAML: prettier
    • Python: black
    • R: styler
  • For local formatting, we provide a Conda environment: [LINK TO FILE AFTER MERGE]
  • After creating the Conda environment locally (conda env create -f formatting.yml), you can use the provided shell script for formatting: [LINK TO FILE AFTER MERGE]
  • For automated GitHub workflow checks, see our exmaple workflow.

[sreichl]

Great, thanks I have added it now to the wiki.

Feedback (feel free to comment on it, maybe there were reasons):

• prettier requires a config file (added to doc/wiki entry)
• prettier was not in the conda env
• conda env did not specify any versions (apart from python)

-> I have addressed all of them already, so no action required (and tested)

[hoferand]

Thanks for adding this to the wiki!

Regarding your feedback:

• The Prettier config file is optional, I would leave that up to the user. However, it makes sense to at least mention it in the wiki, so thanks for that.
• Prettier doesn’t need to be installed in the conda environment; npx can run it directly.
• This was intentional and based on personal preference: libraries that don’t risk breaking the product don’t need to be pinned. I generally prefer using the latest versions (for dev tools), but I understand this is subjective.

[sreichl]

• The Prettier config file is optional, I would leave that up to the user. However, it makes sense to at least mention it in the wiki, so thanks for that.

How do you ensure then that every MrBiomics module would be formatted the same, and what is actually the default? Do we use the default or something specific? If we use the default, we can remove it for maximum simplicity.

• Prettier doesn’t need to be installed in the conda environment; npx can run it directly.

not for me (on our linux HPC). it requested to be installed while running and I didn't want it to be installed using non-conda ways.

• This was intentional and based on personal preference: libraries that don’t risk breaking the product don’t need to be pinned. I generally prefer using the latest versions (for dev tools), but I understand this is subjective.

oh okay, I am just used to the best practice to pin for reproducibility/portability

[hoferand]

The Prettier config file is optional, I would leave that up to the user. However, it makes sense to at least mention it in the wiki, so thanks for that.

The default is the same as in our current config file. So removing is probably easier for most users. (I just added the config file so my VS code extension works properly)

not for me (on our linux HPC). it requested to be installed while running and I didn't want it to be installed using non-conda ways.

You are right, I double checked and its better to have it in the conda env file directly, sorry for that.

oh okay, I am just used to the best practice to pin for reproducibility/portability

Yeah, for workflow environments it absolutely makes sense to pin/lock versions.

Just as an aside: in ecosystems like Rust (Cargo) or JS/TS (npm), strict pinning can sometimes lead to multiple versions of the same dependency being included (if your pinned version differs from what a dependency requires), which can increase build size.

In PHP (Composer), it’s even stricter—if dependencies can’t be resolved to a compatible set of versions, the install fails entirely.