Broken check_characters.py
lissyx opened this issue · comments
Regression from remote IO work:
This fails with
Traceback (most recent call last):
File "training/coqui_stt_training/util/check_characters.py", line 22, in <module>
from .io import open_remote
ModuleNotFoundError: No module named '__main__.io'; '__main__' is not a package
Repro'd on mozilla/deepspeech-train:v0.9.3 Docker image
@CatalinVoss Do you mind checking?
Ah sorry about that! I think two options
- We update the instructions to call this script as a module like
That allows you to call the script from the base directory as long as you specify the right relative module path and there are
python -m deepspeech_training.util.check_characters__init__.pys along the way. - We update the import to
from io import open_remotewhich assumes that you're calling the script from within theutildirectory.
Do you have a preference between these two?
Ah sorry about that! I think two options
1. We update the instructions to call this script as a module like ``` python -m deepspeech_training.util.check_characters ``` That allows you to call the script from the base directory as long as you specify the right relative module path and there are `__init__.py`s along the way. 2. We update the import to ` from io import open_remote` which assumes that you're calling the script from within the `util` directory.Do you have a preference between these two?
I'd prefer 1
It could be awesome if you can add GitHub Actions coverage :)
I updated the docs. It's awesome that you moved to Github Actions -- I love them. However, I couldn't figure out at a quick glance where you'd want to add an invocation of this script in the various workflows. I'm probably not the right person to write a test for this as I've also never used this script…
where you'd want to add an invocation of this script in the various workflows.
I'd suggest adding a new job for that, next to e.g. the C++ binary tests
1. `python -m deepspeech_training.util.check_characters`
So after thinking again, it also means we are breaking backward compatility.
@reuben Do you have an opinion on whether it is sound we break backward compat here?
We update the import to
from io import open_remotewhich assumes that you're calling the script from within theutildirectory.
it's even going to break because io is a python provided module, so usually it should take precedence.
If you prefer, we can also just revert the remote I/O changes for this file, which would mean that you just can’t do this for remote files.
…
On Tue, Apr 6, 2021 at 05:26 lissyx @.***> wrote: We update the import to from io import open_remote which assumes that you're calling the script from within the util directory. it's even going to break because io is a python provided module, so usually it should take precedence. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#3599 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACRFKYFY647VTVZXPWLOTTTHL4YBANCNFSM42JBTP7A .
Either way, current 0.9.3 images and docs are broken, and whatever fix we pick we need to make a new dot release (which makes me unhappy), so I prefer to wwait for reuben's opinion :)
which makes me unhappy
Sorry 😞
It was not against you, it's just that it's not the best time to have to do one. It just proves that what is not tested is broken ;)
@CatalinVoss Do you mind sending the same PR agaisnt r0.9 please?
Reopening for r0.9
@lissyx OK. Are there any other docs to update or is this one file change the only one?
@lissyx OK. Are there any other docs to update or is this one file change the only one?
No it's the same one
@CatalinVoss Thanks!