Move files with optional dependencies to integrations folder#2782
Move files with optional dependencies to integrations folder#2782Adel-Moumen merged 65 commits intospeechbrain:developfrom
Conversation
|
Thanks @pplantinga … this change would be really helpful in adding new tokenizers. Following are also needed to be transferred to integration folder: |
I've added |
In addition, are we keeping a folder for discrete in |
Actually, I transferred all their code to SB so it not dependant on external library, we just initialized the weights with their checkpoints |
Adel-Moumen
left a comment
There was a problem hiding this comment.
Hi @pplantinga, the changes looks good to me. I think you also need to move Flair and spacy folder since they also depend on an external library. I would also advocate for having a README.md in each subfolder within integrations to explain how to install and make the dep and speechbrain working together (e.g. specifying the compatible versions). Finally, I would say that we should also discuss about the folders lobes and the naming conventions. I tend to think that we could increase the readability by having better names and maybe even subfolders? Idk. :)
Added to list above
This could make good sense, we could have the requirements file that pinned a specific working version perhaps, and an author or person to contact if it stops working.
What naming conventions would you change? The "lobes" name itself? |
|
One more question for the crew, up to this point, we've been ignoring the CI tests for the integrations because it adds to the CI time and increases the likelihood that the CI breaks because we have to install a bunch of extra packages (and I'm wondering if some of them might not work on the CI server anyway). Do we want to add these tests back in, or is this something we want to continue skipping and just say that integrations are at your own risk. @TParcollet etc. |
|
There is a long-standing issue with fairseq in newer Python versions (2.11+) that doesn't seem likely to get addressed anytime soon. Should we just go ahead and deprecate our integration? |
|
"speechbrain.nnet.losses.transducer => speechbrain.integrations.transducer ??? Should we deprecate in favor of e.g. torchaudio?" --> No, torchaudio loss is crazily slower than our Numba impl. For the tests, i'd be in favor of having them, but it sounds like a nightmare to maintain. At the same time, we provide this folder as a main part of the library... so our users may expect it to work properly. Could we have a specific CI for this folder? Like one that is only triggered if the code in it is touched? Coverage that we should improve (I think anything bellow 60% is not really acceptable...) and since we are changing everything now, maybe good to put this in that PR?: |
|
Also that is a big PR, reviewing / testing will be slow. |
You are right, its big but perhaps not as big as it looks since most of the changes are to module path names. For reviewing I would recommend just taking a look around the new integrations folder and seeing if the organization / readmes make sense. Some testing should be done too but again the functional changes are mostly just to module path names which should be unlikely to break anything. Biggest risk I guess is that I somehow put the wrong path for something, which recipe tests should catch. |
There was a problem hiding this comment.
rather than discrete, maybe we could have been more specific i.e. audio_tokenizers or something like that.
There was a problem hiding this comment.
i think keeping the full name is better no? speech_tokenizer.py or speechtokenizer.py
There was a problem hiding this comment.
We can't keep the same name as the imported library as this leads to some sort of import error. But perhaps there's a better option than speechtok.py like speechtokenizer_interface.py or something.
There was a problem hiding this comment.
Yeah I understand now. I know that ESPNet is using the convention name tokenizer. E.g. from espnet.espnet2.speechlm.tokenizer import X The only issue with this is that tokenizer is a broad term and can be applied to anything. I am honestly not against having a folder that can have audio/speech tokenizers, as well as text (if one day this happen) or vision tokenizers.
There was a problem hiding this comment.
Btw, shouldn't sentencepiece be moved in the .integrations. folder ?
There was a problem hiding this comment.
Well currently sentencepiece is a non-optional dependency, but integrations is only for optional dependencies. I think we use it enough throughout the toolkit that perhaps its worth keeping it that way.
There was a problem hiding this comment.
same for this one wavtokenizer or wav_tokenizer.py
There was a problem hiding this comment.
wavtokenizer_interface.py ?
There was a problem hiding this comment.
what about speechbrain.integrations.tokenizer.wavtokenizer ?
There was a problem hiding this comment.
shouldn't this file go to discrete folder instead? The model doesn't seems to use the HFTransformersInterface abstract class that we have in huggingface.py. It seems to be more an orchestrator of different pre-trained blocks.
There was a problem hiding this comment.
I think the Python standard for file names is all lower case -- due to different operating systems treating upper/lower case differently.
There was a problem hiding this comment.
yep. I guess everyone in the community of codecs knows what dac refers to. We can keep it lowercase as you suggestd :)
There was a problem hiding this comment.
Is there a specific reason why we are dropping FairSeq support? I tend to agree but maybe we should be more specific about the reason why?
There was a problem hiding this comment.
FB has stopped active development of FairSeq (last released version was 2022) and there is some dependency issue with a new release of some package though I can't remember which one (cuda? pytorch?)
There was a problem hiding this comment.
FB stopping FairSeq, now Torchaudio :(
|
Unfortunately the MERT huggingface model is not compatible with the latest version of transformers (see huggingface/transformers#36134). I'll set up the test with an earlier version but we may have to deprecate at some point. |
|
Okay, this should be pretty much ready to go @TParcollet @Adel-Moumen Any last comments? |
…rain#2782) Co-authored-by: Adel Moumen <adelmoumen.pro@gmail.com>
In internal discussions, we decided to move as much of our external-dependent code as possible into a single folder for a couple of reasons:
The basic concept is that we will add a python module
speechbrain.integrationsthat contains any speechbrain blocks that depend on external libraries. So far we have:speechbrain.nnet.losses.transducer => speechbrain.integrations.transducerDeprecations:
After this approach is verified, I will:
We need to ensure all integrated third-party folders have at least one doctest. Still needed: