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 dev
d 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?