Dynamic versions in editable installations

I personally don’t like seeing packages and libraries do this. It adds extra overhead of an otherwise unnecessary import + call done at startup time in every process using the code that does complicated things to lookup a constant from an external location (elsewhere on the filesystem, etc). Why make all users pay that cost for no good reason?

If you have the concept of a version and want that to be available programmatically at runtime to your users, don’t put it in a __private__ dunder named attribute and populate the constant in code once, at installation time. Also document what guarantees your library makes about what type and format the value will always be, when and why it should be used, and what it means in your API docs.

.__version__ attributes are IMNSHO generally pointless.

5 Likes