Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move cookiecutter templates to their own repository #96

Closed
holtgrewe opened this issue Jun 10, 2022 · 3 comments · Fixed by #170
Closed

Move cookiecutter templates to their own repository #96

holtgrewe opened this issue Jun 10, 2022 · 3 comments · Fixed by #170
Assignees

Comments

@holtgrewe
Copy link
Member

holtgrewe commented Jun 10, 2022

Is your feature request related to a problem? Please describe.
Having the ISA-tab cookiecutter templates inside of cubi-tk makes re-using them burdensome.

Describe the solution you'd like
Move them into a separate repository cookiecutter-collection-cubi-isa-tab. We should the usual convention of having one repository per cookiecutter here as we will always use them from within cubi-tk and not use them separately. Having one repository for each cookiecutter template too much overhead (for now).

cubi-tk should clone the current contents of the repository when being invoked with the templating command.

Describe alternatives you've considered
One could also clone the whole of cubi-tk and extract them where used but that is additional complexity.

Additional context
N/A

@mikkonie
Copy link
Contributor

Note regarding the use of these templates: The one part of the Python code I actually use when using these templates in external software is the _TEMPLATES mapping, which informs me of the currently available templates.

This or something like it should probably be included in the potential separate repository. Otherwise, any software using these templates would need to create their own boilerplate code for recognizing and describing available templates.

@holtgrewe
Copy link
Member Author

The main value of _TEMPLATES is overriding whether the somatic variants calling is triplets (includes RNA-seq) or not. We could have separate repositories for each after all and have a separate one including/excluding RNA-seq.

SODAR could be changed to have a model which allows registering upstream isa-tab repositories and we provide factory presets that include the CUBI ones. Would require work on the SODAR side then.

Maybe we can work around the issue in SODAR by cloning cubi-tk, extracting the _TEMPLATE variable and related things (maybe introduce some #begin/#end marker lines around it), and using the templates from there?

@eudesbarbosa
Copy link
Member

Suggested first step: reorder cubi_tk/isa_tpl/archive - separate cookiecutter from config files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants