Option to reset/clear gin register

[Conchylicultor]

Currently, if a @gin.configurable is imported twice (e.g. through importlib.reload()), it raises an error.

This can be fixed by gin.enter_interactive_mode(), but interactive mode does not clear the previous scopes, which is potentially error prone as all importlib.reload() might interfere with one another. This makes it difficult to keep track of the current registered configurable state.

I would like to be able to clear to reset gin to it's initial state, so I am confident my colab will behave similarly to python script, without having to restart the colab runtime.

[sguada]

You can clear gin registrations with gin.clear_config() and use clear_config(clear_constants=True) to also clear all gin.constants

[Conchylicultor]

Yes, but this does not solve the issue gin.clear_config() reset the parsed config, but not the registered @gin.configurable

@gin.configurable
class A:
  pass

gin.clear_config(clear_constants=True)

@gin.configurable  # Error: A already registered
class A:
  pass

I guess I'm asking for gin.clear_config(clear_registered=True)

The use-case is colab use:

gin.clear_config(clear_registered=True)
with adhoc_import:
  import my_project
  reload_module(my_project)

The second time this gets executed, this will raise an error. As explained above, gin.enter_interactive_mode() feels error-prone

[Conchylicultor]

Another example were this appear is in unittest:

@pytest.mark.parametrize('default', [None, 123])
def test_default_factory_explicit(default):
  gin.clear_config()

  @gin.configurable
  @dataclasses.dataclass
  class Config:
    x: Any = default

Despite gin.clear_config(), the Config class is created twice, thus raising a:

ValueError: A configurable matching 'Config' already exists.

To allow re-registration of configurables in an interactive environment, use:

gin.enter_interactive_mode()

Using gin.enter_interactive_mode() inside a test feel very wrong. It would be much better to have a gin.clear_config(clear_registered=True).

[sguada]

This 334547d should fix this issue, and allow to register the same configurable twice, as far is the same class with the same name.

Can you try to pull the latest version and try again?