Open boxydog opened 1 month ago
It might be from more closely tying delphi-utils
to this repo, perhaps #1460?
Thank you for the report. This will take us a bit of time to address. A few possible workarounds for now:
delphi-epidata
client version to 4.1.20; the main update in 4.1.23 is some logging needed for our internal use; that client version should stay compatible for the foreseeable future (we can let you know in this thread if that changes)Let me know if the first works for you for now and meanwhile we can see what we can do to slim the dependencies on our end.
Thanks so much for your quick reply. I'm happy to pin to 4.1.20 for now, sounds like that could work for awhile.
@boxydog you are exactly right, it is from adding the dependency of delphi-utils
in #1460. The change may add some to the installation footprint, but it should not affect its reliability much if at all; the only functionality used from the added library is in logging.
@boxydog you are exactly right, it is from adding the dependency of
delphi-utils
in #1460. The change may add some to the installation footprint, but it should not affect its reliability much if at all; the only functionality used from the added library is in logging.
Thanks for your reply.
If I include 66 more libraries, then any one of them can have a bug, incompatible version, or other problem that makes it harder just to install the delphi-epidata
library. That's what I mean by affecting reliability, not that the code path will have a bug, but that the dependency will cause support burden. In general, I don't want to rely on code I don't use.
So I hope it's possible to look into slimming down the dependencies to only what delphi-epidata
needs. I understand it can be non-trivial to do so.
@melange396 I started thinking how we could address this and got a couple ideas:
logger.py
from delphi-utils
into a separate delphi_logger
package+repo, put it on PyPI and install from there; this would solve the annoyance of needing to keep these files synchronizedI dont know if its worth it to create a new PyPI package for a dinky little logging config... I am very into deduplicating the logger.py
file though -- the acquisition and server code can use delphi_utils.logger
instead of delphi.epidata.common.logger
, especially because they both already use delphi_utils
in some way or another.
Logging in the client is a fringe case for debugging usage at this point, and as a user facing package, it doesnt really gain much from rigid log-like formatting. What if we just dumb down the logging in the client for now? (I created PR https://github.com/cmu-delphi/delphi-epidata/pull/1486 to demonstrate.) Then, at some point after we take the bloat out of delphi_utils
, we might once again consider using it for logging in the client.
Thanks for your work on epidata.
Between
delphi-epidata
4.1.20 and 4.1.23, you seem to have introduced at least 66 new dependencies, see below. (I have a few in our project already, so you may have introduced more than 66.)I am concerned that introducing all these new dependencies into my production application will make it less likely to be reliable.
Is there any way to get a more slimmed down version of
delphi-epidata
?