-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add template #1
Add template #1
Conversation
@brynpickering @sjpfenninger : Still, I thought it would be good to review it as it is. The only changes would be removing some dependencies. Lots of files, but the important ones are:
|
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
@brynpickering @sjpfenninger I will revert this to use conda |
You can also just include Although I can see the benefit of sticking with one manager and one way to look at setting dependencies (environment.yml files). Some of the benefits of pixi (namely tasks) can be handled natively by snakemake rules anyway. |
Installing recursive environments seems... odd. But losing lock files for the 'project' portion of the data module might be worse... I'll try adding mamba to the pixi dependencies. If that still causes problems I'll revert to |
for more information, see https://pre-commit.ci
@brynpickering thanks for the suggestions! It's now working like a charm. I've added a few improvements to The only change would be updating the dependencies when |
@brynpickering @sjpfenninger |
@sjpfenninger @brynpickering In the future, maybe we could have both if all the functions in The only problem with this is that if the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! I'll try building it on my own machine. In the meantime, there's some minor comments
template/{{ module_short_name }}/.github/workflows/check-latest-template-spec.yml
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made some minor changes following a local build. LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good to me. I made two specific suggestions for making it more explicit that the short name will be used as the directory name for the newly-created module.
Co-authored-by: Stefan Pfenninger-Lee <[email protected]>
Co-authored-by: Stefan Pfenninger-Lee <[email protected]>
@brynpickering @sjpfenninger The last bit is the documentation comment that @sjpfenninger made. I've just removed the generated diagram. |
For documentation: GitHub renders Markdown well, so why not just expect that the documentation of each module is always rendered viewed on the GitHub repository, coupled with a manually populated and maintained list of modules e.g. somewhere on https://clio.readthedocs.io/ (which is where as a user, I'd expect to see the available modules, anyway). More fancy things are always possible later. |
@sjpfenninger agreed. I've simplified things by making all the mkdocs stuff optional, and clarifying important files. This reduces overhead while still ensuring we can provide nice module descriptions in the future. |
Initial template for data modules. Mostly based on
ec-modules
.Features:
pixi
as the package managercopier
questions to pre fill licensing, citation and key bits of the codepytest
testing to check that the produced template works (docs build, pre-made example runs, pre-made testing runs).INTERFACE.yaml
) should fit schemasall
rule throwing a specific error if the module is called as a regular workflow