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

Consistent bystro config naming scheme #393

Open
wingolab opened this issue Feb 3, 2024 · 4 comments
Open

Consistent bystro config naming scheme #393

wingolab opened this issue Feb 3, 2024 · 4 comments
Assignees

Comments

@wingolab
Copy link
Collaborator

wingolab commented Feb 3, 2024

Background:

A concise description of why we're pursuing this task.

The bystro configuration file uses different styles to name keys. It would make it easier if it was more consistent. I suggest lower case with underlines (e.g., snake_case) but recognize this is arbitrary.

Completion Criteria:

What is the goal, and how do we know this task is accomplished?
  • Update the bystro perl code to use lower case with underlines.
  • Convert the existing example genome builds to the lower case with underlines convention.

Implementation Summary

Give enough technical detail for a teammate to understand the proposed solution.

Examine the code base - probably at the build steps - to determine the scope of change that this might entail.

@akotlar
Copy link
Collaborator

akotlar commented Feb 4, 2024

For the perl codebase, the intention was to only use snake_case for CLI arguments, so converting entirely to camelCase will be far easier. Would this be workable?

@akotlar
Copy link
Collaborator

akotlar commented Feb 5, 2024

Thinking about this some more I don't think that will be satisfactory. I'll convert the perl codebase to snake_case in a series of PRs; we'll do it gradually to avoid breaking too much.

akotlar added a commit to akotlar/bystro that referenced this issue Feb 6, 2024
akotlar added a commit to akotlar/bystro that referenced this issue Feb 6, 2024
@wingolab
Copy link
Collaborator Author

wingolab commented Feb 6, 2024

The intention behind my suggestion was around the configuration file and any areas of the code that require adapting to a change from the existing name to one that uses lower case with underscores (e.g., snake_case). I didn't mean that we should change the entire Perl code base to use snake_case.

The bigger issue with the configuration files are their complexity, and what seems like some inconsistency between how track keys are used between different tracks (it was only one track's keys that behaved differently - not recalling it at the moment). This led me to look at configuration languages that 1) could enforce a schema; 2) allow the configuration to be split across several files for readability and maintenance ease; and, 3) would not make us change anything about the YAML and Perl code. I came across pkl that might be something worth considering. It seems like it was just released but the tutorial and docs made me think it would be a few days of work to adapt for our project.

akotlar added a commit to akotlar/bystro that referenced this issue Feb 6, 2024
akotlar added a commit to akotlar/bystro that referenced this issue Feb 6, 2024
akotlar added a commit to akotlar/bystro that referenced this issue Feb 7, 2024
akotlar added a commit to akotlar/bystro that referenced this issue Feb 8, 2024
akotlar added a commit to akotlar/bystro that referenced this issue Feb 8, 2024
akotlar added a commit to akotlar/bystro that referenced this issue Feb 8, 2024
akotlar added a commit that referenced this issue Feb 8, 2024
* Enforces snake_case in python. This auto-converts from camelcase, and
will convert back to camelcase upon serialization. This way our JSON
responses and inputs can follow JSON conventions , but also Python
conventions.
* As part of this submissionID -> submissionId and queueID -> queueId,
because this makes auto-camelization/un-camelization easier
* Fork liftover and fix liftover failure due to
jeremymcrae/liftover#19
@akotlar
Copy link
Collaborator

akotlar commented Feb 8, 2024

I like the suggestion and will look into pkl. I agree the configuration files are complex. Better documentation will help some as well.

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

No branches or pull requests

2 participants