Allow some settings values to differ based on environment

[DannyBen]

This issue was raised in #664.

Some bashly settings may benefit from having different values based on the bashly environment setting (production / development).

Example use case - use formatter: shfmt --minify for production, and formatter: internal for development.

I am wondering what - if any - is the optimal way to implement this:

Option 1: Allow hash syntax

formatter:
production: shfmt --minifydevelopment: shfmt

Option 2: Support settings file per environment

Like in Rails, load settings in this order if the files are found:

• deffault built in settings
• settings.yml
• settings.production.yml / settings.development.yml based on env

Option 3: Do nothing except document the ERB solution style

formatter: <%= Bashly::Settings.production? ? 'shfmt --minify' : 'shfmt' %>

Option 4: Improve the ERB style by providing more context to the Settings reader

formatter: <%= production? ? 'shfmt --minify' : 'shfmt' %>

Option 5: Allow _production / _development suffix on all keys

Implemented in #668

formatter: shfmtformatter_production: shfmt --minify

I am sure there may be some other options.

Finally, if we decide to implement using option 1, then which of the settings deserve such treatment.

1. All of them (except those that are already a hash).
2. Selected ones, such as: target_dir, strict, show_examples_on_error.

If anyone has any opinion on the subject, I am interested to hear.

ping: @meleu@pcrockett@mcblum

[meleu]

My favorite is option 2. I also like option 1. Then I would suggest: between the two pick the one you consider easier to implement and maintain.

I don't like options 3 and 4 and would never use them. I would prefer to externally tweak BASHLY_ env vars (in a Makefile or something) than polute the YAML with ERB tags.

Although I'm a big Ruby fan (I like ERB also), I feel like Bashly shouldn't look like it favors those who know some Ruby (which we already do here).

[pcrockett]

Option 2.

• It seems like a very simple approach (famous last words...).
• It is also the most powerful approach, since it can be used to override whatever you want, both current and future settings.
• It's way less of a hack than the ERB approach.

There's also an option you may have missed: environment variables. One could pretty easily set BASHLY_FORMATTER=shfmt --minify when doing the production build.

Honestly I'd prefer the environment variable approach until it becomes apparent that a lot of people are overriding a lot of settings based on environment.

[meleu]

I'd prefer the environment variable approach until it becomes apparent that a lot of people are overriding a lot of settings based on environment.

I second this! 👆

Suggesting my fellow countryman @marlondecol (hey bro! 🇧🇷) to handle the BASHLY_FORMATTER env var in a Makefile or something would be better.

(by the way, @marlondecol, I've just published a bashly tutorial in our native language here. Maybe you'll like it. 😉 )

[marlondecol]

@meleu hey, guri! Nice article, I really liked it. Thanks!

[DannyBen]

Interesting.

I did not mention the bashly environment variables, since this it is a bypass of the built in bashly generate --env production, and requires external tools. If external tools are used, then there is no need to change formatter in bashly at all - simply run the formatter in your Makefile.

Option 2 is much easier to implement.

[marlondecol]

I also liked the 2nd option, since it’s already familiar to the community given that other technologies implement it as well.

I’d also suggest implementing development and production settings to define a specific set of settings for each environment. This way, there would be no need to create an extra settings file per environment. It would be the inverse of the 1st option: instead of environment-specific definitions inside the setting scope, the setting itself would be placed inside the environment scope. Following the given example, it would look like this:

formatter: shfmt # In the global scope; in this case, applied only in development.production:
formatter: shfmt --minify # Applied only when in production.

The 4th option could improve readability, but @meleu’s arguments are undeniable!

[DannyBen]

I’d also suggest implementing development and production settings to define a specific set of settings for each environment.

This would be a lot of work. Probably the most work out of all the options. I am not sure I want to go there...

[marlondecol]

No worries, I actually thought it would be less work than dealing with the extra files.

[DannyBen]

Hmm.... I spoke too soon.

On paper, loading an additional config file is trivial. However, since the env value is considered a settings value on its own, we end up with an endless loop, where the config path is based on the env, which is based on the config file(s).

defenv@env ||= get(:env)&.to_sym# <== expecting a fully built config objectenddefconfig@config ||= defsult_settings.merge(user_settings).merge(env_settings)enddefenv_settings@env_settings ||= File.exist?(env_settings_path) ? Config.new(env_settings_path) : {}enddefenv_settings_path@env_settings_path ||= user_settings_path.sub(/(\.[^.]+)$/,".#{env}\\1")# <== calling envend

[pcrockett]

Hm, does it make sense to refactor so the env value isn't part of settings? In a lot of technologies, an "environment" is a concept that controls what settings are applied. It tends to be outside, not inside, the settings.

That said, I'm still in favor of not implementing anything yet 😁

[DannyBen]

does it make sense to refactor so the env value isn't part of settings?

It probably does.

[DannyBen]

I have added Option 5:

formatter: shfmtformatter_production: shfmt --minify

The suffix can be any environment, and on any option.

Easy to implement, document, and use.

Thoughts?

[DannyBen]

settings.yml not bashly.yml - but I see your point regardless.

[meleu]

I am not so happy with the patchy state of the settings, but I guess this is a concern for a 2.0.0 as it will be breaking.

Since you brought this, I feel comfortable to mention a minor thing that bugs me a bit...

It seems to me that the strict setting should go in bashly.yml and not in settings.yml.

(maybe Scripting Options too, but my original discomfort came from the strict setting)

The two reasons I have in mind:

1. bashly.yml looks more like a place for things that happen "inside the code", while settings.yml seems to be a place for settings for how to generate the code.
2. as "bash strict-mode" is something that people may want to tweak right away, a newcomer must be aware of the settings.yml (prematurely, IMO).

---

A quick story about my first experiences with Bashly:

(I don't remember how I discovered it)

Look the gif in the README, "wow! that looks cool!"

Skim the docs, read the "Getting Started". Slightly disappointed, that's too few information, but still excited by the gif.

Read "Writing Your Scripts", got a better idea, but still feeling unable to make use of Bashly.

Next page in the docs: "Settings". 🥵 Gave up.

But, damn!, I'm still excited by that gif. Let's jump to the Examples. Alright, now I'm starting to feel able to use it. Let me create something by myself...

Started working in zxz and wanted to use my favorite way of "strict-mode": set -Eeo pipefail. "Oh, I saw something about initialization in the "Writing Your Scripts" session. Alright, I'm gonna put my strict-mode there.

Days later I noticed the Hook Files Alternative session and realized that the strict setting is a thing and that I must aware of a settings.yml file if I want to use strict-mode in a Bashly way.

[DannyBen]

Interesting.

The bashly.yml file represents the data structure for a Script::Command. What to place in the initialization, has nothing to do with it, when considering this perspective. Anything that does not belong to Command does not belong in bashly.yml.

I can relate to what you are saying, but the separation is quite clear cut now, just perhaps not visible from all perspectives.

• The Getting Started section of the docs is definitely too shallow.
• The Settings (and Testing) section in the docs perhaps need to be located later. Originally, I mostly intended to have the smallest number of "subsections" possible to avoid overwhelming.
• I invested a lot of time in the examples, so at least they played their part in bringing you back on board 😉

When it comes down to it - I think that if someone spends time reading the entire bashly documentation - cover to cover - they will still save a lot of time in writing their bash scripts. Even if they end up having to create another file called settings.yml or - if they prefer - set it using environment variables in .envrc.

If you want to be proficient in something, you need to study it. That said - if there are things that can improve the experience for newcomers, I am all for it. I have been knee-deep in it, so my view is definitely skewed.

[meleu]

I hope you don't take that as a personal criticism. Your tool is wonderful and your effort to make it shine is pretty apparent.

Your work on the examples is awesome and your gif in the README (and bashly.dev frontpage) is a very good way to capture the attention of those who already suffered creating CLIs with Bash.

if there are things that can improve the experience for newcomers, I am all for it.

I have some ideas, but first I want to collect feedback about the tutorial. I'll open a thread when I feel ready to execute.

[meleu]

By the way...

Anything that does not belong to Command does not belong in bashly.yml.

This is a good sentence to reorganize my mental model of Bashly and its files. Now I'm even wondering if it should could also be named as bashly-commands.yml, just to make the intention more explicit.

(not a strong opinion here, just brainstorming)

[DannyBen]

I've just published a bashly tutorial in our native language here.

@meleu - this looks cool, shouldn't we link from the wiki?

[meleu]

I've just published the English version here:

https://dev.to/meleu/create-robust-cli-apps-with-bashly-5gb0

I'm gonna add the link. 👍