Conditional code generation in commands that depends on `generate --env` value.

[tzah4748]

I would like to be able to include certain parts of the code only in development/production environment.
The idea resembles how a C compiler's preprocessor uses #ifdef sections.

I know that by default the env is only taken into consideration at generation time, I would expect to be able to access it in the command itself to define sections that should be generated according to its value.

For example (The syntax can change to fit your taste) :
download_command.sh

# command.env.production
echo "This will only be included in the final script if --env production was given to bashly generate"
echo "This too, until saying otherwise, all code after the above commend is included only in production"
# command.env.development
echo "This will only be included in development"
# command.env
# OR alternatively
# command.env.~
echo "This will be added in any env, which should be of course the default case :)"

[DannyBen]

Yes. Assuming I understand you correctly, I had this thought before, and I think we may have even discussed this somewhere in the discussions or issues.

Correct me if my understanding, as described below, does not match your request.

---

Bashly will search for command files in a priority order. For a command named copy in a development env, it will first look for copy_command.development.sh and only then for copy_command.sh. The first file found, is merged into the result script.

This way, if you want to have an "environment override partial" - you just change the extension to <environment>.sh

---

Correct?

[tzah4748]

Right, the above is a full override of the command, I seek to merge only specific sections of the command script.

EDIT:

1. To emphasize this more, I need to be able to use one _command.sh script that includes different sections, some will be compiled by default and some are compiled only when a certain env is specified. By "compiled" I of course mean merged into the result script.
2. Default sections and development sections can be one and the same... meaning only production section is really needed

[DannyBen]

Oh - your edit completely turns this on its head.

You are talking about the equivalent of some #IFDEF in C right?
Like one file with "special markers" that describe a condition, and if this condition is not met, the section is used/ignored.

This is unlikely to happen. This requires reading each and every file, and starting to parse it for our own new invented markers, which are most likely going to be "magic comments", which starts to turn this into something more complex.

I thought you meant something more along the lines of what Rails is doing by allowing an optional "environment pre-extension" on filenames:

src/copy_command.production.sh    # < will be used when --env production
src/copy_command.sh               # < will be used anywhere else

For the latter implementation, it can probably be done relatively easily here:

bashly/lib/bashly/concerns/renderable.rb

Lines 41 to 47 in efe753a

	def user_file_path(file)
	path = "#{Settings.source_dir}/#{file}"
	ext = ".#{Settings.partials_extension}"
	return path if path.end_with? ext
	"#{path}#{ext}"
	end

[tzah4748]

Understood, if this is complicates things and gets out of the scope of bashly that's fine. Feel free to close

[DannyBen]

Leave open for a while - maybe a suitable solution will present itself. Feel free to comment further if you have anythin gto add, or come up with another approach that will not require parsing the partials.

[tzah4748]

The only "workaround" I could think of involves in adding an environment variable that can be used later in commands implementation to execute certain parts of the code only when the variable is provided or meets a certain value.

Assuming we have environment variable named ENV it can be used like that:
We can execute certain commands with ENV set to whatever and the command will react accordingly.

if [[ "${ENV}" == "production" ]];
    echo "ENV is set... doing production stuff"
fi

This is not the same as actually removing certain pieces from production code but still OK for some use cases.