-
Notifications
You must be signed in to change notification settings - Fork 1
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
Rename "profiles" to "build-configs" #27
Conversation
797da19
to
e89096f
Compare
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.
This LGTM as a direction. I'm not sold on the exact term "customizations", but I don't have a better suggestion!
I'm not super happy about the term "customizations" either but I can't think of anything better. Definitely open to other people's suggestions 😄 |
I think of the contents/meaning of those files/directories as defining "builds", since they include parameters and often other input files and custom commands required for the workflow. That name falls short of our definition of "build", since these files don't include all of the commands. We do tend to call these files "builds", though, in ncov. I didn't like "customizations" initially, since it seems to downplay the critical nature of these files, but it's growing on me. It does seem to cover the combination of parameters plus custom (🙃) files and rules. |
I'm also iffy on "customizations" and I think the reason is that it's typically used to represent something more specific. I'll try to explain below. In comparing "configurations" vs. "customizations", both represent modifications of the software's default behavior. The difference lies in whether the modifications are formally supported features.
Ideally these would be classified separately, where most usage can be done with configurations alone, and only a few special cases need customization. The ncov workflow makes these concepts distinct: the configuration file supports additional customizations via custom_rules. Currently this repo structure doesn't define structure that deeply, and maybe it shouldn't. I also can't think of a better name. Just wanted to share thoughts about why "customizations" sounds weird here. |
@victorlin I think you've hit the nail on the head for why "customizations" isn't sitting easy with me. |
Yeah, this is also part of why "customizations" doesn't feel right: generally if you're customizing something you have a single set of changes to tailor to your purposes. Here, we have many different sets of changes that seem to want/deserve their own proper noun and concept less abstract than "customizations" (or "configurations" for that matter). "Builds" would be in the running there… |
…but they are colocated with the commands in the workflow. And in one sense the configs and input data determine the commands which the workflow will run. I think there'd be a decent case made for calling these "builds" or "build configurations". |
Thanks for spelling out "configurations" vs "customizations" @victorlin! This made me think of video game mods, which encompasses both...How would people feel about "modifications" or "build_modifications"? |
"Modifications" makes more sense than "customizations", but isn't commonly used to describe "tailoring software to suit one's needs". I like the idea of centering on configurations (@tsibley's suggested "build configurations") that can optionally be extended with customizations - ncov already sets precedence for this. However, "configurations" would be confusing with the existing |
That's fair!
I'll go with |
(Maybe it's just me, but can we consistently use hyphens instead of underscores, e.g. |
Based on discussion in #27. Renaming "config" to "defaults" to prevent confusion with the new "build-configs" directory to be in the following commit.
To avoid confusion with Snakemake's Profiles¹, rename the "profiles" directory to "build-configs" based on discussion in #27. This is expected to include subdirectories for specific build configs that include both config params and custom Snakemake rules that extend and/or override the core workflow. This also allows us to rename the build specific configs from "defaults.yaml" to "config.yaml" since they no longer clash with Snakemake Profile configuration files. ¹ https://snakemake.readthedocs.io/en/stable/executing/cli.html#profiles
e89096f
to
4043f03
Compare
Part of work to update this repo to match the pathogen-repo-template. Always provide default config values that can then easily be overridden with --configfiles/--config options. This makes it simpler to change a subset of config values or extend the default configs. Renames the config/ to defaults/ to reflect this change. Match changes in pathogen-repo-template in nextstrain/pathogen-repo-guide#27
Based on discussion in nextstrain/pathogen-repo-guide#27. Renaming "config" to "defaults" to prevent confusion with the new "build-configs" directory to be in the following commit. Conforms to the pathogen-repo-guide's new directory structure. https://github.com/nextstrain/pathogen-repo-guide/tree/89b3c5dbc9b8f6a009f4a19c3ac56113bc5511ee
Description of proposed changes
Rename "profiles" to
"customizations""build-configs" to avoid confusion with Snakemake's Profiles.This allows us to also rename custom configs to
config.yaml
since it no longer clashes with Snakemake's Profile configs.Related issue(s)
Motivated by feedback in #24
Checklist