@auguste.gardette: I've (Claude actually) started building nf-core modules for your tool. We're finding some small issues. Here are the two current ones: "Stale internal version string. epac/version.py still has SATIVA_BUILD="v0.9.1" / SATIVA_RELEASE_DATE="2023-08-16" — untouched since the fork's SATIVA v0.9.3 base, even though the bioconda package is at 0.9.3.4. Every run's own startup log (SATIVA_INFO % progname) claims to be "v0.9.1," which is actively misleading for anyone debugging or filing a bug report against a specific release. Combined with there being no --version/-version flag at all, there's no way for a caller (us included) to ask the installed tool what version it actually is — I had to reverse-engineer it from the conda package's installed path (share/sativa-epang-<version>-<build>/, baked into the sativa-epang wrapper script at build time) rather than anything the tool reports itself. Worth suggesting he bump SATIVA_BUILD on each release tag and/or add a trivial version flag. 2. Silent GTR+G fallback if -refmodel is omitted with -reftree. The help text says -refmodel's default is GTR+G — but nothing stops you from passing -reftree without -refmodel, so a caller who forgets the model flag gets scored under a silently-substituted, possibly-wrong substitution model with no warning, rather than an error. Since our module always passes both together, this doesn't bite us — but it's a footgun for any other caller of the staged CLI. Worth either erroring when one is given without the other, or at least logging a visible warning." I suppose we should post that as issues on your repo, correct?