What to use in v0.7 in place of `Pkg.dir`

General Usage
,
1

In v0.7.0-beta the use of Pkg.dir produces a warning

julia> using Pkg

julia> Pkg.dir("Statistics")
┌ Warning: Pkg.dir is only kept for legacy CI script reasons
└ @ Pkg.API API.jl:432
"/home/bates/git/julia/usr/share/julia/stdlib/v0.7/Statistics/"

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?

1 Like
2

This seems to be a work in progress (there are some subtle potential ambiguities):

https://github.com/JuliaLang/julia/issues/27592

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"))
3

This is the right answer. In the future, there may also be a separate mechansim for bundled example data/models, but not yet.

4

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.

5

@__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.

6

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.

7

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.

1 Like
8

I use 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.

9

FWIW Pkg.dir was not correct in Pkg2 either so its not like there is a loss of functionality.

10

Yes, 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.

Regards

Avik

11

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.

2 Likes
12

Yes, for things like Documenter and Coverage that explicitly deal with packages something like this is likely needed and is why I opened https://github.com/JuliaLang/julia/issues/27592.

1 Like