Rename "profiles" to "build-configs"

[joverlee521]

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

• Checks pass

[tsibley]

This LGTM as a direction. I'm not sold on the exact term "customizations", but I don't have a better suggestion!

[joverlee521]

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 😄

[huddlej]

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.

[victorlin]

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.

• "Configurations" are formally supported features (e.g. a command line option like augur filter --min-date).
• "Customizations" implies extension of the underlying software with new features (e.g. extension of workflow with new rules).

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.

[tsibley]

@victorlin I think you've hit the nail on the head for why "customizations" isn't sitting easy with me.

[tsibley]

@huddlej wrote:

That name falls short of our definition of "build", since these files don't include all of the commands.

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…

[tsibley]

…since these files don't include all of the commands.

…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".

[joverlee521]

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"?

[victorlin]

"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 config directory. I just caught up on discussions in #24, and if I'm understanding correctly, config is only used for defaults. In that case, I'd propose to rename config → [configuration_]defaults (like ncov) and use customizations → [build_]configurations here.

[joverlee521]

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.

That's fair!

In that case, I'd propose to rename config → [configuration_]defaults (like ncov) and use customizations → [build_]configurations here.

I'll go with defaults and build_configs to keep them short.

[tsibley]

(Maybe it's just me, but can we consistently use hyphens instead of underscores, e.g. build-configs? Pretty please?)