Feat/train

[martinsbruveris]

Ongoing work on a training framework.

[martinsbruveris]

The way the registry works (as far as I understand) is that we don't have to import everything in the module where it is used, it just needs to be imported somewhere. Basically, the python interpreter needs to process the class definition at which point it will register it.

For model architectures this takes place automatically, because all model architectures are imported into tfimm/__init__.py.

And if we use the libary in our project and define a problem or trainer outside the library, we can still use the registry provided by tfimm.

[hyenal]

Gotcha, but then you would one way or another import all the registered models right ?

I am asking about this import because I am wondering if the registry shouldn't be build by the user. In the sense that when you use this code you may want to develop your new dataset. But while you develop it you cannot train anything at all because you would import your new dataset with probably faulty code. So here I would generally prefer a dynamic import since you would use one problem/trainer/dataset so no need to import other code.

This comments stems from my lazy experience where I did this and ended launching one branch training and then going back to the other for development. Doing dynamic import just enabled me to avoid branch switching if I wanted to launch training on older network while developing (we can do this a lot)

[martinsbruveris]

The idea is that the registry itself is provided by the library and the user can add their own classes to the registry. For example, this repository implements the pyramid vision transformer and adds it to timms model registry. So that if you add import pvt_v2 at the top of your module, you can use timm to create the model via timm.create_model("pvt_..."). I am envisaging something similar here.

The library needs to be in control of the registry, otherwise it can't provide functionality to parse configs, etc.

Regarding your problem, there are two ways around this:

• You have control over what is being imported by default. To stop a particular class being registered, you just have to remove (comment) the corresponding line from the __init__.py file.
• Only the module needs to be importable. The code does not have to be executable. For example, this is fine:

# My module code
def f():
    assert False

This is a valid module and I can register f() without problems, even though executing it would raise an error.

[hyenal]

Thanks for the answer:) I like the idea of the registry even more now it makes a lot of sense