# Module version standard/convention

**URL:** <https://discourse.julialang.org/t/module-version-standard-convention/34686>\
**Category:** General Usage\
**Tags:** package, module\
**Created:** [February 15, 2020, 6:33pm UTC](https://discourse.julialang.org/t/module-version-standard-convention/34686 "2020-02-15T18:33:53Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![tk3369](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tk3369/32/2824_2.png) [@tk3369](https://discourse.julialang.org/u/tk3369)\
**Post date:** [February 15, 2020, 6:33pm UTC](https://discourse.julialang.org/t/module-version-standard-convention/34686/1 "2020-02-15T18:33:53Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 16, 2020, 7:05am UTC](https://discourse.julialang.org/t/module-version-standard-convention/34686/2 "2020-02-16T07:05:29Z")

</div>

> [@tk3369](#):
>
> can dynamically figure out the version of a module that’s loaded in memory?

What’s the use case?

---

<div class="post-metadata">

**Author:** ![tk3369](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tk3369/32/2824_2.png) [@tk3369](https://discourse.julialang.org/u/tk3369)\
**Post date:** [February 16, 2020, 7:38pm UTC](https://discourse.julialang.org/t/module-version-standard-convention/34686/3 "2020-02-16T19:38:24Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)\
**Post date:** [February 17, 2020, 12:07am UTC](https://discourse.julialang.org/t/module-version-standard-convention/34686/4 "2020-02-17T00:07:06Z")

</div>

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

> <https://github.com/JuliaLang/julia/issues/33210>
>
> \`\`\`
> julia\> using Example
> 
> julia\> pathof(Example)
> "/Users/kristoffer/.julia/p…ackages/Example/aqsx3/src/Example.jl"
> 
> (v1.2) pkg\> add Example@0.5.1
> Resolving package versions...
> Updating \`~/.julia/environments/v1.2/Project.toml\`
> \[7876af07\] ↓ Example v0.5.3 ⇒ v0.5.1
> Updating \`~/.julia/environments/v1.2/Manifest.toml\`
> \[7876af07\] ↓ Example v0.5.3 ⇒ v0.5.1
> 
> julia\> pathof(Example)
> "/Users/kristoffer/.julia/packages/Example/kH44X/src/Example.jl"
> \`\`\`
> 
> I would have thought \`pathof\` should point to the path as it was when the module was imported. Not the file that would have been used if the module was not imported but got imported right now.

(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`).

> [@Tamas\_Papp](#):
>
> What’s the use case?

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.