Conversation
…ory}.py, utils/{debug_env,env_factory,make_env}.py
feat: allow passing combined suite and scenario e.g. "gymnax/CartPole-v1"
|
Hey, so this is great but a few points. I dont think we should include any envpool or gymnasium dependencies into stoa as its designed mainly for JAX envs. The envpool and gymnasium wrappers should remain in stoix. Second, i think the application of wrappers should also be on the stoix side. My thoughts for the registry in stoa would be more simple such e.g. stoa.make('brax/ant', env_kwargs), this would only make the base environment and wrap it with the adapter. I dont think we want to be applying any wrappers on top. As you did in this PR though, it would be nice to have an extra utility function for core wrappers. |
|
Let me know when this is ready for review |
|
Sorry for the delay -- I think this works! In the gymnax_env, env_params = gymnax.make("CartPole-v1")
env = GymnaxToStoa(gymnax_env, env_params)with env = stoa.make("gymnax", "CartPole-v1")The stoa environment doesn't have an extra "params" object, so only the environment is returned. |
|
Amazing! Let me give it one last look but i think its good. |
Closes #1. I've copied over stoix.utils.make_env and some of its dependencies. The tricky part is getting rid of the hydra dependency since requiring the user to put all the arguments in a
DictConfigis poor UX -- plain keyword arguments are more Pythonic. This means that somehydra.utils.instantiatecalls will need to get called downstream, i.e. in Stoix.