Rename `run` function to `main_run`

[meleu]

Description

I'd like to suggest renaming the default run function to something like main_run.

Reasoning: prevent name collision with BATS run function.

I already have a solution for this: I always put this in my bashly-settings.yml:

function_names:
  # NOTE: this is needed to prevent name collisions with BATS-core
  run: main_run

It's not a big thing for me, who already realized how to solve it. But it's another thing that adds more friction to let people (or AI agents) start testing right away.

[DannyBen]

Well - maybe lets ask BATS to change their run function... 😜

So as it turns out, this reply has two sections:

Table of Contents:

• I Disagree
• I Agree

---

The run command is currently guaranteed as a developer-interface function, to allow rerunning functions internally by passing ARGV.

I know it is a rather weak argument, and there are probably no more than a handful of users using it - but still, changing something that feels natural, so that it wont conflict with a testing framework is arguably just as weak.

And by the way - I think you should avoid sourcing the entire bashly-generated script for your bats tests.
Since in bashly you already have different functions in different files, you can just source them.

I have used this approach in all my bats tests. Example:

• https://github.com/DannyBen/ssi/tree/master/test
• https://github.com/DannyBen/alf/tree/master/test
• https://github.com/DannyBen/shellkin/tree/master/test

Furthermore - I had a case where I needed to have a run() function that is NOT the bashly one, so I also used the settings to do so, and still, I was able to test with bats by using this trick:

eval "$(declare -f run | sed '1s/^run /bats_run /')"

which redeclares the bats run function as bats_run

Can be seen in play here

---

That said - I agree that run is a function with many potential conflicts.

Maybe a less conflicty name for it would be main()? and it would still serve the contract for developers, as they can run things like main mycli --with args and it will feel somewhat as natural.

How about this?
If we do want this - should we consider this a breaking change?

[meleu]

Maybe a less conflicty name for it would be main()?

I don't think this is a good idea, because bash, by default, name the "top level context" as main. You can see an evidence in the stacktrace example:

./download: line 15: no_such_command: command not found
./download:15 in `root_command`: no_such_command

Stack trace:
	from ./download:15 in `root_command`
	from ./download:259 in `run`  # 👈 if we call this `main`, we have duplication
	from ./download:267 in `main` # 👈 `main` is the name of the "very-first caller"

---

I think you should avoid sourcing the entire bashly-generated script for your bats tests.

You're right, it's an overkill to source the whole final script to test a single function. Maybe I just got used to do this in my pre-Bashly days.

Now I feel like this "feature request" issue should be moved to discussions while I reflect about my current bash testing practices... 🤔

[DannyBen]

Good to know about main's secret identity.

I don't mind continuing the discussion here, it will either quickly mature to a feature, or die out.

In general - I don't mind renaming, only it needs to be a good, natural name, and we will need to consider if it is a breaking one or not.

[DannyBen]

@meleu you always make me think, I like that.

It occurred to me that perhaps both of us are doing the bats sourcing wrong:

• You source the entire script (artifact) - so you end up with a lot of junk and run() collision
• I source only the function-under-test and its dependency chain - so I end up with many sources and "unsource" cleanups

What if we just add a "load all src/lib/*" in the test helper? Something along these lines:

# test_helper.bash
load_lib_tree() {
  local file
  while IFS= read -r -d '' file; do
    source "$file"
  done < <(find "${BATS_TEST_DIRNAME%/}/../src/lib" -type f -name '*.sh' -print0 | sort -z)
}

Note that this will work only for lib files, which are encapsulated as functions, and not for the "command" files.
For the command files, this is a whole new ballgame, which - I think - does not belong in a unit test framework, but rather in some integration / acceptance testing, that can either be done with bats (by actually running the CLI) or using another acceptance-friendly framework.