-
Notifications
You must be signed in to change notification settings - Fork 30
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
[Feature Request]: Leverage optional dependency groups to reduce dependency count #928
Comments
Interested in thoughts from @munrojm , @jmmshn , @Andrew-S-Rosen and others on this |
I think that your proposal makes sense, with updated documentation to reflect the "extras" needed for a given I definitely would avoid the namespace stuff for the reasons you stated. |
Based on the graph |
Also, it doesn't appear that |
Makes sense re: fastapi, boto3, and mogogrant. I'd support their use as optional dependencies. Re: |
I am all for this. Would just want to make sure it is appropriately scoped w.r.t to the default store types supported. My opinion is that It would be nice to support the FYI, pyzmq is only used for the distributed builder running. |
Problem
As recently surfaced in a peer review of a package that depends on
maggma
,maggma
introduces a LOT of dependencies (ultimately because it so versatile). However, any given user ofmaggma
is probably only using it to connect 2 or 3 types ofStore
and might not make use of many of these.Proposed Solution
Our
setup.py
already leverages optional dependency groups for certainStore
. My suggestion is to double-down on this concept so that by default,maggma
is installed only with a mininmum set of depdendencies to enableMemoryStore
JSONStore
MongoStore
With all other more specialized stores requiring optional dependency groups.
Our current
setup.py
Related, the
API
components carry a whole separate set of dependencies. Perhaps those should be broken into their own dependency group.Alternatives
An alternative would be to break
maggma
into namespace packages forBuilder
,Store
, and the API components. I'm not a fan of this option as I find maintaining and installing these really confusing (see: emmet!)The text was updated successfully, but these errors were encountered: