Agreed!

I was trying to figure out why an API from Vaex 3.x was no longer working, and to my human eye, this quickly pointed me at the issue. However as a way to automatically check for versions, this is a mess. I have no idea what additional keys the next version might add or remove, for example. I'm not even sure if this is dynamically determined based on optional components being installed or not.

Providing this kind of information *somehow* feels like a useful thing to do. But .__version__ is probably not the right way to do it.

On Wed, Apr 14, 2021 at 5:08 PM Christopher Barker <pythonchb@gmail.com> wrote:

On Wed, Apr 14, 2021 at 7:48 AM David Mertz <mertz@gnosis.cx> wrote:
>>> vaex.__version__
{'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5': '0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter': '0.6.0', 'vaex-ml': '0.11.1'}

Well, THAT is a great argument for some official standardization!

There is sometimes a need for that sort of thing, but I think it's best handled by either putting __version__ in each sub_package, or having a different attribute altogether.

-CHB

--
Christopher Barker, PhD (Chris)

Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython

The dead increasingly dominate and strangle both the living and the
not-yet born. Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.