Removing plugin system from gymnasium

[pseudo-rnd-thoughts]

Hi Jesse,

The Gymnasium developers are thinking about deprecating several changes for v1.0, one of these is the plugin system that I believe you initially added for Atari. Given v1.0 and no new plans for API changes, we would be interested in adding gymnasium support in ale-py as this will make it easier for users to understand to load atari environments, they need to do gymnasium.make("ale_py:Pong-v0") rather than gymnasium.make("shimmy:Pong-v0") (shimmy is a compatibility project we have primarily for deepmind environments to use the gymnasium API).

What are your thoughts? We are not planning on releasing v1.0 for several months but I wanted to get this discussion started early

Mark

[JesseFarebro]

Hi Mark,

I'm open to this, we should plan to do this for the v1.0 release. However, I'd like to suggest something that's similar to the previous plugin system as I don't want to register the Gym/Gymnasium environments in the root ale-py package itself.

My proposal would be to still leverage Python entry points (these are standardized in the spec and well-supported by tooling). I don't want to have to check for Gymnasium and register our environments if it exists. The reason is that when we register our environments we traverse the filesystem to discover which ROMs are registered and this could potentially be expensive. I want to minimize the time required to load our module.

Solution: Allow us to define an entry point for Gymnasium that will resolve when the user imports the package via gymnassium.make('ale-py:*'). So if a user specifies a package in the make call (e.g., ale-py:*) Gymnasium does the following:

1. Check if a gymnasium.envs entry point exists for this package. If it exists it'll use this as the registration module, i.e., it imports this module.
2. If the entry point doesn't exist then it'll just import the module verbatim as specified in the original call, i.e., import ale-py in this case.

How is this different from how the plugin system currently works? The key difference is that the original design tried to resolve all plugins when gym was loaded. I agree that this probably isn't the right thing to do and could be fairly error-prone.

Thoughts?

[pseudo-rnd-thoughts]

Hi Jesse,

Apologies for taking so long to get back to you, I went on holiday then forgot you had replied. I think our preference is to remove all entry-points and to go back to the old system where users would import the environment module which would register the environments in the background to allow them to be installed.

I understand that you don't want to search the users filesystem to discover what ROMs are registered but I don't understand the advantage of using an entry-point over registering the environments when the module is loaded. These seem very similar to the normal user.

Our aim with the registration system is to make it as easier as possible for users to load / register environments from a module. In short, we would like users to go back to the following for all environments except the internal gymnasium ones

import gymnasium as gym
import my_env

env = gym.make("env_id-v0")

with the option of users doing

import gymnasium as gym

env = gym.make("my_env:env_id-v0")

for cases where users want to define the environment in a file that can't load a module

I hope this makes sense why we don't want to use entry-points.

Therefore, it would be helpful for us if ale-py was updated to this system and in the process added gymnasium support. I would be happy to make the PR if you wish.

Open to hear your thoughts on the idea