Closed melange396 closed 4 months ago
So of course, I end up finding the perfect guide for this (by the Python Packaging Authority) only after we fix it, but it's all good because this guide provides many approaches and we ended up doing approach (2) they recommend here single-sourcing the package version. And interestingly, approach (5) is the one we did previously and it has this caveat:
Be aware that the importlib.metadata API only knows about what’s in the installation metadata, which is not necessarily the code that’s currently imported.
So maybe that's the edge case we ran into 🤷
Change the way the python client determines its own version number.
The current implementation uses
importlib
to get the "installed version" of the package and set it in the user-agent string. This is apparently fragile enough that is misreporting its version number to the API server (in a number of places on our own systems, no less!). Maybe it worked better in the past before it was updated to stop usingpkg_resources
. ¯\_(ツ)_/¯On a single one of our automation servers, different jobs make requests that announce user-agents of both
delphi_epidata/0.0.11 (Python)
anddelphi_epidata/0.0.12 (Python)
(among others!). To make it even more ridiculous, the addition of the "(Python)
" suffix didn't come around until version 4.1.0. This does suggest the possibility of a misconfiguration of some sort on the machine, but the way the client is implemented makes that even more difficult to track down.Unless someone has a better idea, we can keep something like the existing
try
structure and attempt to get the version from the package but fall back to the "0.script" text if it doesnt work, or we could just be lazy and adddelphi_epidata.py
to the bumpversion config.