Is it possible to activate the extras/test dependencies of a project, e.g. for running tests manually/interactively (instead via Pkg.test()
)?
cd into the directory and start julia there with julia --project
. Then in package mode do instantiate
. Then include("runtest.jl")
(or whatever).
Sure, that activates the project and it’s deps become available. But the packages in [extras]
, resp. referred to by test = ...
in [targets]
aren’t part of a normal project activation. At least I’ve never had them available by just activating/instantiating a project. Have I missed something?
No easy way:
https://github.com/JuliaLang/Pkg.jl/issues/624
I usually manually create the project file and activate it
Ah, thanks Mosè! I was wondering if there was an issue about it, but didn’t find it.
I guess for debugging complex packages, one would also want all optional deps (loaded via Requires.jl) of the package in question available … but that’s of course beyond the job of Pkg.
Oh silly me - the optional/Require deps should obviously be part of the test deps of the package already, so no problem there.
Post Julia 1.1 solution:
Setup:
- Create a
test/Project.toml
- in it all your test-time dependencies.
- Remove them and the other test time stuff from the main Project.toml
use
For testing ] test
will work as before.
For manually activating:
- Activate the main environment
- Do
push!(Base.LOAD_PATH, "./test")
, (assuming currently directory is in basedir of project) - You should now be able to using any package from either
Project.toml
This feels like a gross hack to me.
There has been issues about creating nicer ways to activate stacked environments.
Maybe @StefanKarpinski or @kristoffer.carlsson have more thought in this direction
Yes, thoughts to make it better. Will happen at some point
Is this approach stable now? I like it much better, but it had bitten me before:
https://github.com/JuliaLang/Pkg.jl/issues/1788
For this to work, I think it is necessary for test/Manifest.toml
to exist. To create it, do ]activate test
and ]instantiate
.
But then version resolution doesn’t seem to happen jointly. I’ve had more success with working in the test
environment and doing ]dev .
.
A bit late to the party, but TestEnv.jl now exists and solves exactly this problem.
Yes, TestEnv.jl is great, thanks again to @oxinabox for creating it!