A community effort to collect a curated set of analysis pipelines built using Nextflow.

nf-core

FYI: Installing tools from scratch via `conda` does not give me `prek`, so I get errors when running. Bioconda recipe probably wants updating?

<@UQZG2UCF3> you lied to me on 4.0.1 :sob:

May be nice to add a test to the bioconda recipe that lints a known good pipeline or something like that.

it's not that sort of linting unfortunately

Well I guess we could but it starts making very heavy tests

Yeah, that's probably not ideal for bioconda tests

What j find strange is that given if comes from pypi why it doesn't check the dependencys updated there

Could be a nice feature request for BiocondaBot :)

The prek dependency was added in 4.0.0 :grimacing:

Then what's the issue with <@U03R5TJ77GF> :eyes:

That the conda package doesn't provide `prek`  in the runtime dependencies

The joke being that 4.0.1 didn't add new dependencies from 4.0.0 :)

We can hijack the 4.0.2 bump to add it I reckon: <https://github.com/bioconda/bioconda-recipes/pull/64986>

Maybe `tools` needs a `nf-core validate-ext-deps` command that just checks that nextflow, prek, nf-test etc. are on the path? And that gets run in the bioconda recipe

Yes but it's a bit strange that a package has to check whether its dependencies are installed as you expect the installer to do that for you.

You can't list dependencies on an external tool in a pyproject.toml file, AIUI, as pip wouldn't be able to install them anyway. And on top of that, Bioconda doesn't actually ever pull the deps from pip - they need to be changed manually.

A check that the deps are installed helps capture drift between the various packaging options compared to the source.

In this case, `prek` is a listed dependency in pyproject.toml/PyPI. James' suggestion that the bot checks the pip dependencies against the ones listed in the recipe may make this process less error prone. Also for other python package recipes. But I also understand that this kind of checks can become non-trivial very quickly given how complex dependency resolution can get.

Yeah I spoke about this elsewhere. `prek` and `pre-commit` are a bit weird because they are *runtime tool dependencies* but because they are also python packages you can sort of make them get installed by making the packages become dependencies of your package. But this is not really what package dependencies are meant for, it's intended for libraries which you use in your code. I'm not even sure that if the Python packaging peps guarantee any cli commands will be installed. 

Given these tools are not used as libraries in the code I would actually prefer we removed them as library deps and just made users install them like we do other cli dependencies like git 