-
Notifications
You must be signed in to change notification settings - Fork 358
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
Reduce package size #251
Comments
Thank you for the suggestion! Reducing package size would be helpful but I'm not quite sure what the suggested implementation would look like. Take How would you suggest removing those packages but still keep functionality of KeyBERT? Also, if these packages are needed but for some reason need a separate installation, how would you suggest making it possible that |
Im glad you are looking positvely on this suggestion. To make dependencies optional, there are a few elements that can be used:
try:
from fast_query_parsers import parse_query_string as parse_qsl
except ImportError:
from urllib.parse import parse_qsl as _parse_qsl In this example (see source here) we try to import an optional dependency. If there is an ImportError is raised, a fallback is assigned instead. This could be used for example to implement alternative logic in utils etc.
The answer is to switch to runtime backend selection. This is a breaking change, and thus it will need to be implemented in a v1.0.0 to work. Basically, the user has to install a backend - either using a extra dependency group, or by installing it separately. |
How would something like this be relevant for KeyBERT? I believe this is already implemented. There are many optional installations that you can do outside of the main package for different backends: https://maartengr.github.io/KeyBERT/guides/embeddings.html
The thing is, nearly all users will make use of
I'm not sure whether this is ideal as this would mean that Let me rephrase my initial question. I believe you cannot remove If these packages are not necessary for the functionality of KeyBERT, could you explain why? |
in this case it is impossible. This though makes it difficult to use this library in contexts where the size of the library is an issue. |
That's too bad. I hoped that since you specially mentioned |
Hi and thanks for this great library.
I am encountering a common problem with ML libraries using KeyBERT - namely, the package is very large due to its dependencies. E.g.
torch
is a gigantic library (used in thesentence-transformers
li),scikit-learn
is very large etc. This makes it very difficult to use this library in a serverless context due to cloud function size limitations and cold start issues.I would like to suggest working to reduce the package size. This can be done by making some dependencies optional and adding guards against them.
The text was updated successfully, but these errors were encountered: