Relative imports, RETURNN import_, or intended more stable?

[albertz]

Relative imports can be difficult to read in some cases when you need to go up a couple of packages.
Sth like from returnn_common... import ... can look nicer and cleaner in some cases.

However, this currently is not possible when it should work with the RETURNN import_ mechanism.

Maybe we can somehow fix the RETURNN import_ mechanism to make this possible, although I'm afraid this would be hacky, and I don't see a simple solution currently. (If we want to go this route, let's open a separate issue in the RETURNN repo about this.)

The question is also whether we need import_ here. import_ is intended for unstable code which can easily break. But in e.g. i6_experiments we handle this differently:

• Common code (in common subdir in i6_experiments) is supposed to be relatively stable and not break too much, or tries to be compatible for older setups. (It's not really settled, and maybe less strict than RETURNN itself, or i6_core, but still.)
  This corresponds to the code we have here directly, e.g. in models, etc.

• Users code (in users subdir in i6-exp) can be as unstable as someone wants. There are no guarantees.
  We have the same here, although naming might be different (we would not have a users sub-dir but instead custom modules with some postfix, like conformer_chris.py or so).

So maybe this is fine, and then we do not need import_. Instead, we can handle this repo in a similar way as i6_experiments, clone it into the recipe subdir for Sisyphus, and make it also available for RETURNN configs.

[JackTemaki]

Instead, we can handle this repo in a similar way as i6_experiments, clone it into the recipe subdir for Sisyphus.

I would suggest to go with this way, as this will be the most convenient and obvious solution for Sisyphus users.