Motivation and Context

One task I have to do frequently is to start a “default” simulator (mostly for writing custom viewers). The only option I am aware of is to use the code in habitat-sim/examples/settings.py to get a default configuration. Having to rely on this file has been a pain point. I have to either run my scripts from the examples folder or the sim folder (this leads to inconsistent imports: on some files the statement is from settings import ..., on others it is from examples.settings import ...). I can also play around with sys.path or PYTHONPATH, but this not a viable solution since it can clash with other packages that also have folders named examples or files named settings.

This PR moves the settings.py file into habitat_sim.utils, thus making its functionality unambiguously available everywhere. I kept a file named settings.py inside examples that simply imports the original settings file to make sure existing scripts that rely on it don't break.

How Has This Been Tested

Tests (some of which rely on this file) pass. The existing examples also continue working.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have completed my CLA (see CONTRIBUTING)
• I have added tests to cover my changes.
• All new and existing tests passed.