-
Notifications
You must be signed in to change notification settings - Fork 27.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split model list on modality #18328
Split model list on modality #18328
Conversation
The documentation is not available anymore as the PR was closed or merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really awesome and really needed ❤️ thanks for working on that.
We could perhaps also split up the models in the main README, as well as the "big table of models", although I'm not sure about that. cc'ing @sgugger
This requires more work than just splitting the navigation bar (as seen with the failing quality test). There are scripts that format this model ToC/check all models are documented which then need to be adapted. Likewise splitting the big tables of models in the main README will require to rewrite a lot of the scripts that copy it to other READMEs and the index. |
I have made the necessary changes to the quality script that is failing but:
You can find the changes in in this branch, just cherry-pick the commit. Giving authorization to the maintainers to push on your branch when opening a pull request would make the whole process way smoother. Or just use the main fork (huggingface/transformers) instead of your personal fork :-) Edit: Managed to open a PR by hacking some urls in GitHub (thank you for showing me @LysandreJik !). It's here. The changes in the toc are just rewrites from the Python yaml library. |
Adapt script to reorg
* 📝 split up model list * Adapt script to reorg * apply niels feedback Co-authored-by: Sylvain Gugger <Sylvain.gugger@gmail.com>
This PR splits the model API list on modality because it was becoming difficult for users to discover what vision or audio models are supported because they just disappear in the long list. I set these sections to not expand by default since users are more likely interested in going straight to a modality and then expanding the list of supported models instead of scrolling past all the text models, for example.