Skip to content

Relative imports, RETURNN import_, or intended more stable? #2

@albertz

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions