As per the issue in https://github.com/openai/gym/issues/2407 raised by @lebrice there is some legacy code that checks the entry point of the Atari environment. This can actually be solved in an elegant way by taking advantage of how namespace packages are installed.
If we package gym/envs/atari/* while excluding __init__.py at gym/ and gym/envs/ BUT including __init__.py at gym/envs/atari our subpakage will get installed to Gym as we'd expect. This allows the ALE to remain in control over the environment code while not breaking the entry point of gym.envs.atari:AtariEnv.
Furthermore, with the new plugin architecture in https://github.com/openai/gym/pull/2383, https://github.com/openai/gym/pull/2409 we can now register our environments as well as the legacy environments using the plugin architecture. This has the advantage of auto registering the ALE/*-v5 environments without needing to import ale-py.
As per the issue in https://github.com/openai/gym/issues/2407 raised by @lebrice there is some legacy code that checks the entry point of the Atari environment. This can actually be solved in an elegant way by taking advantage of how namespace packages are installed.
If we package
gym/envs/atari/*
while excluding__init__.py
atgym/
andgym/envs/
BUT including__init__.py
atgym/envs/atari
our subpakage will get installed to Gym as we'd expect. This allows the ALE to remain in control over the environment code while not breaking the entry point ofgym.envs.atari:AtariEnv
.Furthermore, with the new plugin architecture in https://github.com/openai/gym/pull/2383, https://github.com/openai/gym/pull/2409 we can now register our environments as well as the legacy environments using the plugin architecture. This has the advantage of auto registering the
ALE/*-v5
environments without needing to importale-py
.