In v0.7.0-beta the use of
Pkg.dir produces a warning
julia> using Pkg
┌ Warning: Pkg.dir is only kept for legacy CI script reasons
└ @ Pkg.API API.jl:432
but without any indication of what should be used instead.
If I include sample data with a package and want to illustrate how to access that data, I could use
dat = load(Pkg.dir("MixedModels", "test", "dat.rda"))
in earlier versions. What would a v0.7 alternative be?
This seems to be a work in progress (there are some subtle potential ambiguities):
For your use case, consider defining something like
exampledatapath(filename) = joinpath(@__DIR__,"..","test",filename)
in your source tree, so users do
dat = load(MixedModels.exampledatapath("dat.rda"))
This is the right answer. In the future, there may also be a separate mechansim for bundled example data/models, but not yet.
That works for
Pkg.test but, unfortunately, not for my case, which is writing a tutorial on using the package.
I want to write a reproducible expression allowing the user to access the data file without any assumptions on the working directory.
@__DIR__ is not the “working directory”, it is the directory of the file the macro appears in. So, if you define
exampledatapath(filename) in your module, it won’t matter what directory the user is calling from.
This is a common situation, and has various solutions. Perhaps some elements form the design of the R package here could be adapted to Julia.
I ended up needing this thing pretty often, and was wondering whether by default the package generator could add a
const __sourcedir__ = @__DIR__
line by default (in MyPackage.jl), so that one could always use
MyPackage.__sourcedir__ to refer to the package.
Pkg.dir in package
A but want to look into package
B. In those cases
@__DIR__ does not work. Why can’t we simply have/keep
Pkg.dir(m::String)? Within our loading machinery such a thing must somewhere exist, so why not simply expose it. We previously had static package directories where things have been very easy. Now the package dir is dynamically changing (whether in dev mode or not) and in turn it would be good to leave existing package authors not alone.
Pkg.dir was not correct in Pkg2 either so its not like there is a loss of functionality.
Pkg.dir() did not work in all situations in Pkg2. It just prevented people with non standard setups to use your package. Hence the removal.
In particular, it did not work when the package was built into the standard image, did not work when packages were loaded via LOAD_PATH. It was also problematic in centrally managed package directories.
I just noticed that
Pkg.dir is used extensively in Documenter.jl to build documentation for other packages. This is a good example of something that needs to find the directory of another package (which may not even be imported yet). (Similar usage can be found in Coverage.jl.)
Both Documenter.jl and Coverage.jl are extensively used in Julia packages, and their usage of
Pkg.dir will need a non-deprecated replacement in 0.7.
Yes, for things like
Coverage that explicitly deal with packages something like this is likely needed and is why I opened https://github.com/JuliaLang/julia/issues/27592.