Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes to the new registration #2771

Merged
merged 26 commits into from
May 5, 2022
Merged

Conversation

RedTachyon
Copy link
Contributor

Update to #2748, turns out a few comments from @Markus28 didn't show up, and some of them actually pointed out bugs, so it's necessary to get them fixed.

@pseudo-rnd-thoughts
Copy link
Contributor

pseudo-rnd-thoughts commented Apr 22, 2022

For the bugs that were found, is it possible to add tests for them to prevent such bugs from happening again?

@Markus28
Copy link
Contributor

Could you also explain how this function

def load_env_plugins(entry_point: str = "gym.envs") -> None:

is supposed to be used?

@Markus28
Copy link
Contributor

Is gym.envs.registry supposed to remain backwards compatible? The scripts for gym-docs, for instance, are currently breaking on the master branch because they use gym.envs.registry.all().

@RedTachyon
Copy link
Contributor Author

Could you also explain how this function

def load_env_plugins(entry_point: str = "gym.envs") -> None:

is supposed to be used?

That's out of scope for this, it was introduced by @JesseFarebro a while ago, and by now I think I mostly understand what it does, and it does desperately need documentation (which I'll probably have to discuss with Jesse), but it's mostly orthogonal from these updates.

@RedTachyon
Copy link
Contributor Author

Is gym.envs.registry supposed to remain backwards compatible?

My approach here was to keep it "mostly compatible for reasonable uses", which is as vague as it sounds.

registry.all() is imo something that shouldn't have really happened in the first place, and supporting it for backwards compatiblity would be at least somewhat cursed (although it would be possible, and I have an idea on how to keep the cursedness to a minimum)

That being said, it is the exact equivalent of registry.values() in the new code. Old registry was a wrapper around a pimped-up dictionary. New registry is just a dictionary, and I like it being just a dictionary (simple is better than complex)

@RedTachyon
Copy link
Contributor Author

For the bugs that were found, is it possible to add tests for them to prevent such bugs from happening again?

I'll try to add some tests soon

@RedTachyon
Copy link
Contributor Author

I added a test, ultimately the main issue was around handling the namespace context manager, which is in practice only used in ALE so far, and tests don't cover that. So the test does a basic sanity check that the namespace gets added the way we want it to be.

@pseudo-rnd-thoughts
Copy link
Contributor

LGTM @jkterry1

@jkterry1 jkterry1 merged commit 971aea8 into openai:master May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants