Research single file generation for settings API

[mkundu1]

We shall need this to reduce number of files from the package.

[hpohekar]

@mkundu1

This idea looks good to me.

I would like to discuss how following scenarios are handled currently. How settings are able to identify arguments with same name from their specific file ? How following cases will be handled using a single file. Thank you.

1. a_1.py, a_2.py and a_3.py contain exact same class.

2. If we see file_name.py and file_name_*.py then we have following variations.

class file_name(String):

class file_name(Filename, _OutputFile):

class file_name_1(Filename, _InputFile):

[hpohekar]

@seanpearsonuk @mkundu1

Findings are as follows:

1. The file size is still huge even after separating the class definitions into other file. If we write only class names in a nested structure then it's 32 MB and at this point we have not written attributes of each class and considering that addition the file size will be too higher than 32 MB per Fluent version.

2. We have classes with same name but with different parents. We have handled this issue but even if we separate class definitions then main challenge is to import all classes with same name.

3. Another challenge is that few classes have same name, parents but different docstrings. Same import challenge here as mentioned above.

Insights from all discussions are as follows:

1. The main objective of separating single file into multiple was it's size.

2. There is not any performance issue while using single vs multiple settings files.

Suggestions to handle this challenge:

1. Use single settings file for all releases.
   e.g. We can check whether settings_222.py exists, if not we can generate this for the first time and use it without need of generating it for every launch of Fluent. I think the hash mismatch issue will be not there as we are going to use same Fluent to generate this single file.

2. Use single settings file for older releases only but use settings zip for the latest Fluent release.