Module version standard/convention

In the Python world, you can find out the current version of a module by querying _version_ attribute of the module.

Is there any reason why we shouldn’t adopt a similar standard/convention so that one can dynamically figure out the version of a module that’s loaded in memory?

Given that the version number is already specified in Project.toml, it would be even nicer if it is automagically defined when a module is loaded.


What’s the use case?

When I wrote this post, it’s more from a convenience perspective. I did using XYZ from the REPL and then did some Pkg up command several times to resolve some other package version conflicts. Then, I didn’t remember what was the version of XYZ that I just loaded earlier. So, it would be great if I can just query what version was loaded in memory.

Come to think of it a little further: let’s say package A uses package B and is compatible with v1.0 and v1.1. In my environment, I have both A and B-1.0 installed. When A runs, it could suggest to the user that B can be upgraded to take advantage of the new features from B-1.1 e.g. performance.

If pathof is fixed we can just use Project.toml as the single source of truth and look up the version dynamically:

(Currently pathof does not reflect the package loaded in memory.)

Embedding the version number to precompiled cache is doable but tricky. You may want to use include_dependency on Project.toml so that changing version in Project.toml triggers re-precompilation. However, if you do that, other changes in Project.toml also triggers precompilation (e.g., tweaking compat).

I think it’s useful for, e.g.,

  • Support multiple versions of upstream package (when you want to do it). It’s no different than if VERSION < ... for supporting multiple julia versions.
  • Checking compatibility of code loaded via Requires. Though it’s probably much better to solve this by treating compat information of non-deps packages.
  • Telling your version number to the peer of RPC.