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

Saving more provenance information #205

Closed
pvandyken opened this issue Dec 7, 2022 · 4 comments · Fixed by #308
Closed

Saving more provenance information #205

pvandyken opened this issue Dec 7, 2022 · 4 comments · Fixed by #308
Assignees

Comments

@pvandyken
Copy link
Contributor

The problem

This issue is somewhat relate to #182, but more specifically concerns what information is saved in the auto-generated snakemake.yml file. Currently we keep the entire config, any arguments passed to run.py (including snakemake args), and the snakemake and output directories. For full replicability, it would also be helpful to save the apṗ version (related to #85), and the snakemake version used to run the pipeline.

@akhanf
Copy link
Member

akhanf commented Dec 7, 2022

I agree!

For the app version would we need to force users to expose the version in a particular way?

@pvandyken
Copy link
Contributor Author

Yeah, so that's the tricky bit, there's no one correct way to do this. Of the options listed here, the pkg_resources approach is probably the most method agnostic.

One other tricky is mid-release development version. Other apps will use git hashes as part of the dev versions, but poetry doesn't handle this directly. One would probably need a git precommit hook with versioneer or similar. But also check out this: poetry-dynamic-versioning. I think I'll make a separate issue about it, it looks pretty cool.

@pvandyken
Copy link
Contributor Author

One more related thought: so long as we're reconstructing the config file from scratch, and given the order of attributes is arbitrary, it might be nice to purposefully organize things (and even put comments in if that can be managed... not sure) to make the file as human-readable as possible.

@akhanf
Copy link
Member

akhanf commented Dec 8, 2022

yes a more human-readable config would be great!

@tkkuehn tkkuehn self-assigned this Jun 2, 2023
@tkkuehn tkkuehn linked a pull request Jun 15, 2023 that will close this issue
4 tasks
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