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.,
if VERSION < ... for supporting multiple julia versions.compat information of non-deps packages.