MatthiasZepper
commented
10 months ago For the --tower download, this is exactly what it already does. Check the WorkflowRepo class and associated methods. When DownloadWorkflow.download_workflow_tower() is executed, the repo is checked out at every requested tag/revision/commit and the container detection is run (if desired).
At the moment, WorkflowRepos are however initially downloaded from Github, unless there is already a cached version from a previous run. It would be relatively straightforward to adapt that class to support local repos at custom paths, yet it would somewhat contradict the purpose of a pipeline download tool if no pipeline is to be downloaded?
Some things that one would need to account for:
- Error handling: At the moment, the tool expects that the folder it references to is a git repository, which needs to be checked for arbitrary local folders
- We would also need some "Looks like a pipeline" checks in place, so people do not run it on wrong repos.
- Differentiating between local and Github references might be tricky:
nf-core download rnaseqe.g. currently works, because we assume it refers to repos of the nf-core organisation. But in the future, it could also mean a local folder./rnaseqThe easiest is probably to check first for a local folder and if that does not exist, try to retrieve from Github/Gitlab etc.
For now, I was very conservative and wrapped the old code into a download_workflow_static() method, but in the future it probably helps to always use local git repos (WorkflowRepo) and then to regular clones instead of bare clones for the static downloads. The only downside to that is, that this introduces git as a mandatory dependency - the static download still works on systems with no git installed.
Description of feature
Related to #2406
nf-core download could support a local repo, by performing all the functions after retrieving the repository itself i.e. zipping it up, downloading the singularity containers. This could be part of #2406 or as a related method.