[BFCL] Standardize TEST_CATEGORY Among eval_runner.py and openfunctions_evaluation.py

[HuanzhiMao]

There are inconsistencies between the test_category argument that's used by eval_checker/eval_runner.py and openfunctions_evaluation.py.

This PR partially addresses #501 and #502.

[CharlieJCJ]

LGTM

Comment: improve warning message in the future, make them more information for user to know immediate action items when aggregating results for data.csv.

[HuanzhiMao]

LGTM

Comment: improve warning message in the future, make them more information for user to know immediate action items when aggregating results for data.csv.

Good point. Will address this in a different PR.

[ShishirPatil]

Hey @HuanzhiMao and @CharlieJCJ I don't think this is a great idea for the following reason. So we start by showing how to install the dependencies, and then in the middle we go into a long extempore on the different flags and then we come back with a list of commands to run. This ain't helpful back and forth? Maybe we retain the previous structure where after each command we show the options so users have the context on the command. Thoughts?

[HuanzhiMao]

Hey @HuanzhiMao and @CharlieJCJ I don't think this is a great idea for the following reason. So we start by showing how to install the dependencies, and then in the middle we go into a long extempore on the different flags and then we come back with a list of commands to run. This ain't helpful back and forth? Maybe we retain the previous structure where after each command we show the options so users have the context on the command. Thoughts?

How about we move the flags section to the bottom of the README, just like how all the available model names are displayed at the end?

[devanshamin]

I have solved this issue here.

[ShishirPatil]

Hey @HuanzhiMao and @CharlieJCJ I don't think this is a great idea for the following reason. So we start by showing how to install the dependencies, and then in the middle we go into a long extempore on the different flags and then we come back with a list of commands to run. This ain't helpful back and forth? Maybe we retain the previous structure where after each command we show the options so users have the context on the command. Thoughts?

How about we move the flags section to the bottom of the README, just like how all the available model names are displayed at the end?

I don't think this solves it right? We should present the flags when the user cares about the command, not super down. Folks read and execute code from READMEs linearly, and making them jump around isn't a good idea imo.