I do not understand how test-specific dependencies are meant to be used in interactive work.
To make this concrete, suppose that package Foo has
using Foo
using Test
using Bar
in test/runtests.jl. There is also a test/Project.toml that specifies Test and Bar as dependencies. Importantly, these are not dependencies of Foo.
Pkg.test() works fine when Foo is the active environment. However, it is occasionally useful to run tests interactively. Currently I
- activate
Foo (] activate .. with test/ as the current directory), and evaluate using Foo. Otherwise it is not found.
- then I
] activate . the test directory, and evaluate the rest of the test code.
This is a bit cumbersome, so I must be missing something.
1 Like
The current situation is clearly sub-optimal and it would be really nice to fix Pkg.jl#1233.
With the setup you describe I would simply add Foo to test/Project.toml using a relative path. You would then have something like:
$ tree .
.
βββ Manifest.toml
βββ Project.toml
βββ src
β βββ Foo.jl
βββ test
βββ Manifest.toml
βββ Project.toml
βββ runtests.jl
2 directories, 6 files
$ pkg --project=test dev .
Resolving package versions...
Updating `/tmp/tmp.w9xxYUTzYF/Foo/test/Project.toml`
[8722260b] + Foo v0.1.0 `..`
Updating `/tmp/tmp.w9xxYUTzYF/Foo/test/Manifest.toml`
[8722260b] + Foo v0.1.0 `..`
Note that I devd with a relative path (.) and that the path for Foo in test/Manifest.toml is stored relative to the project (..).
Another way I often use is to simply add the test dependencies to the main project (but not committing it, obviously).
Edit: I forgot to mention the TestEnv.jl package, which tries to mimic Pkg.jl#1233. I have not used this myself though.
1 Like
lmiq
3
What if they are added to [extras] of the main Project.toml? Are they installed when the package is installed? What at the drawbacks of this approach?