Move gym from habitat_baselines to habitat

[vincentpierre]

Migration Guide

Changes to imports :

When importing the gym definitions, you must replace :

import habitat_baselines.utils.gym_definitions as habitat_gym

with

import habitat.utils.gym_definitions as habitat_gym

---

When importing the render_wrapper, you must replace :

import habitat_baselines.utils.render_wrapper as habitat_gym

with

import habitat.utils.render_wrapper as habitat_gym

---

If you were using habitat_baselines.common.baseline_registry to register a RLEnv, you must now use habitat.registry to do so.

---

Changes to configuration files

The following configuration keys no longer belong to habitat_baselines configs :

GYM_AUTO_NAME
GYM_OBS_KEYS
GYM_ACTION_KEYS
GYM_DESIRED_GOAL_KEYS
GYM_ACHIEVED_GOAL_KEYS
GYM_FIX_INFO_DICT
REWARD_MEASURE
SUCCESS_MEASURE
SUCCESS_REWARD
SLACK_REWARD
END_ON_SUCCESS

Their respective replacements are now in the habitat task configs:

GYM:
    AUTO_NAME
    OBS_KEYS
    ACTION_KEYS
    DESIRED_GOAL_KEYS
    ACHIEVED_GOAL_KEYS
    FIX_INFO_DICT
TASK:
    REWARD_MEASURE
    SUCCESS_MEASURE
    SUCCESS_REWARD
    SLACK_REWARD
    END_ON_SUCCESS

In addition, a new key :

GYM: 
    CLASS_NAME

needs to be added to the task config file with the same value as the current ENV_NAME of the corresponding habitat_baselines config (default value is RearrangeRLEnv).

Motivation and Context

In order to separate habitat from habitat_baselines, we move the gym environments to habitat. This enables users to quickly start using the habitat environments without having to install the habitat_baselines trainers.
Reward and success definitions have been moved from baseline configuration to task configuration.
Modified configs creation script to allow modification of the task config from the baseline config.

How Has This Been Tested

Tested that training starts for all of the registered gym environments tasks
Added a unit tests that runs one episode of each gym environment

properly behaves.

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.

[Skylion007]

@vincentpierre Pre-commit is now working properly again. Feel free to pull form master to resolve.

[ASzot]

This impacts all tasks, including non-rearrangement tasks (like PointNav/ObjectNav) are we okay with this?

[vincentpierre]

How big is the impact do you think? How may users make a distinction between the baseline registry and the habitat.registry?
I am having a hard time figuring it out.

[erikwijmans]

This should be fine. It'll impact users that are getting envs out of the baselines registry/registering their own envs, but it's a simple enough fix and this change overall makes sense.

[ASzot]

What's the purpose of this? Shouldn't this only be through config, not the TASK_CONFIG as with habitat baselines configurations?

[vincentpierre]

The reason is because I want to allow the user to pass either a task config or a baseline config to make the environment. If the user passes a baseline config, this code will look at the task config and use it. Does that make sense ?

[aclegg3]

LGTM. Thanks for the migration guide!