Dependencies in `./test/Project.toml`

Tooling Package Management
,
1

According to the Pkg.jl docs for Julia versions >1.2 it is recommended to create a test environment, activate ./test. Here, your package foo is automatically added and you can add relevant packages such as Test.jl. However, when I do this foo’s dependencies are not available in the test environment, e.g.:

     Testing Running tests...
ERROR: LoadError: ArgumentError: Package JuMP not found in current path.
- Run `import Pkg; Pkg.add("JuMP")` to install the JuMP package.

I’ve found that doing this

] activate ./test
add JuMP

avoids the error above. But this causes duplication in dependency declarations. I imagine with this workflow it is also possible to test with incorrect versions and/or you could have extra packages in your test env allowing your tests to pass.

Is my usage of the test environment incorrect? If so, how should I be defining dependencies?

Also, I’ve seen a lot of established packages, such as Flux.jl and JuMP.jl are defining test packages under the extras section. Again, according to the Pkg.jl docs this method is only suggested for Julia versions 1.0 and 1.1, which neither JuMP nor Flux support.

1 Like
2

The test project approach has some issues so many packages don’t use it. Unfortunately the Pkg documentation is pretty misleading on this point. See e.g. Clarify current fragility of `test/Project.toml` approach · Issue #1788 · JuliaLang/Pkg.jl · GitHub.

4 Likes
3

I see, so should I use the extras method and ignore the suggest Julia versions?

4

Yeah, that’s what I do. It’s a bit annoying because you have to edit the extras section manually, but often I just do ] add MyTestDep to get the UUID into the Project.toml under [deps], and then I cut-and-paste it over to the [extras] section.

3 Likes
5

Okay, thank you this is what I’ll do.

6

I personally find the separate test Project.toml approach more convenient to use, and haven’t seen issues like the one referred to in @ericphanson’s link. Those issues probably only arise when you keep the Manifest.toml file stored together with the package, which isn’t really done anywhere often.

As for repeating common dependencies in two Project.toml files: this isn’t really complete duplication. For example, a package can support a wider range of package or julia versions than its tests. Then you just put corresponding different compats in those Project.toml files and everything works fine.
And often you don’t need most of the package deps in the tests anyway, so duplication is minimal.

3 Likes
7

TestEnv.jl can also be used to load the test environment as it is in testing.

1 Like