Add v2 RETURNN config serialization - #601
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
0f01f84 to
960e2b2
Compare
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
Who else should review this? |
|
@michelwi Maybe? If you prefer, we can also do a quick pair programming/review session Monday. :) |
michelwi
left a comment
michelwi
left a comment
There was a problem hiding this comment.
I took the liberty to add some tests. Some of them currently fail.
| # I'm not really sure about it. | ||
| # Our automatic mechanism will find direct imports (e.g. i6_experiments). | ||
| # However, it will not find indirect imports (e.g. sisyphus), | ||
| # and thus the generated code might fail. | ||
| # So add all other paths here which we currently have. |
There was a problem hiding this comment.
Are we now sure? -> remove/rewrite comment otherwise, lets try to make sure
There was a problem hiding this comment.
Well, I'm still not sure about it, but that is the solution we are using now. We can strip the "I'm not really sure about it." if you want. But I'm still not sure whether that's the best solution.
But then, when are you really 100% sure about sth? But here, I'm maybe a bit less confident than for most of the other code that I write, so that's why I specifically mentioned it.
Co-authored-by: michelwi <michelwi@users.noreply.github.com>
I reckon it occurs often enough in RETURNN configs that we can make serialization prettier for it
Co-authored-by: michelwi <michelwi@users.noreply.github.com>
was a left-over special case that we should not handle here as it's also a delayed object
Co-authored-by: michelwi <michelwi@users.noreply.github.com>
|
🎉 |
5 participants
This PR adds an adapted version of the v2 serialization written by @albertz. I intend for this PR to house discussion on what features to support in v2 serialization and what not to support.
The adaptations I made mainly concern themselves around being compatible with existing RETURNN configs that use the v1 serialization mechanisms like the
Import,PartialImport, etc.