Allow packages to easily retrieve their version

[omus]

Allows for packages to codify their own deprecations for future revisions. I example of deprecating the return type of a function:

if @__VERSION__() < v"1.4"
    """
        f() -> String
    """
    function f(; classic_return::Bool=true)
        if classic_return
            Base.depwarn("`f` will return `nothing` in version 1.4")
            return ""
        else
            return nothing
        end
    end
elseif v"1.4" <= @__VERSION__ < v"1.5"
    """
        f() -> Nothing
    """
    function f(; classic_return=nothing)
        if classic_return !== nothing
            Base.depwarn("`f` will no drop support for the `class_return` keyword in version 1.5")
        end
        return nothing
    end
else
    """
        f() -> Nothing
    """
    f() = nothing
end

[KristofferC]

I think this should just look at the Project file of the package itself, not of the project/manifest of the active environment which seems like a very roundabout way of getting to the place where the version actually was defined.

So something like (using JuliaLang/julia#33128) and with error checking

project_data = Pkg.TOML.parsefile(joinpath(pkgdir(@__MODULE__), "Project.toml"))
return VersionNumber(project_data["version"])

This seems to encourage having a bunch of dead code around though.

[codecov]

Codecov Report

Merging #1501 into master will increase coverage by 0.02%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1501      +/-   ##
==========================================
+ Coverage   87.27%   87.29%   +0.02%     
==========================================
  Files          25       25              
  Lines        5383     5393      +10     
==========================================
+ Hits         4698     4708      +10     
  Misses        685      685

Impacted Files	Coverage Δ
src/Pkg.jl	90.9% <ø> (+0.9%)	⬆️
src/API.jl	94.69% <100%> (+0.05%)	⬆️
src/utils.jl	83.33% <100%> (+4.76%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 50f9c6c...4ac07f9. Read the comment docs.

[omus]

I think this should just look at the Project file of the package itself, not of the project/manifest of the active environment which seems like a very roundabout way of getting to the place where the version actually was defined.

How can we locate the path of the package when in sub-module? I'm under the impression you meant pathof when you said pkgdir?

[omus]

This seems to encourage having a bunch of dead code around though.

I agree this will leave dead code around for a while. This however is better then forgetting to remove a deprecation when you do a version bump

[fredrikekre]

JuliaLang/julia#33128

[KristofferC]

This should only be used at top level so the result ends up in the precompile file and so that no runtime parsing of the project file is needed.

[omus]

Code should be ready to go

[StefanKarpinski]

While this is better, it seems like if we're going to officially support this, we should it right and record the tree hash and version number at the time something was loaded, rather than this, which can become out of sync after loading.

[tkf]

Maybe it makes sense to re-compile when the version in Project.toml is changed?

Suggested change

	project_data = TOML.parsefile(Types.projectfile_path(pkg_dir))
	toml_path = Types.projectfile_path(pkg_dir)
	include_dependency(toml_path)
	project_data = TOML.parsefile(toml_path)

[IanButterworth]

I believe Base.pkgversion (new in 1.9) provides the same functionality https://docs.julialang.org/en/v1.9.0-rc3/base/base/#Base.pkgversion-Tuple{Module}

Please feel free to reopen if not, just a tidyup close