[ANN] TestEnv.jl: Activate your test enviroment, so you can use your test dependencies

Package Announcements
1

Often when debugging a failing test I want run a snipped of code in the REPL from my tests.
But often that snippet uses something (like ChainRulesTestUtil) which is not a main dependency of my package, just a test dependency.

If using the 1.2 feature that adds seperate test/Project.toml you can hack around with your LOAD_PATH to kinda get this to work, but that doesn’t work if you use the [extras] section of the main Project.toml (which I kinda prefer), and it doesn’t work on 1.0 etc.
And using the separate test/Project.toml requires you to drop 1.0 support.

Wouldn’t be nicer if I could just do TestEnv.activate()?
and have that work on all julia versions and both ways of setting up your test dependencies ?

Mal Miller and I have created a package: TestEnv.jl which allows you to do just that.
Full credit to the Pkg developers for doing the actual hard work to write code for having test environments, that we hacked up to make it possible to activate them.
We basically cut the sandbox in half, so that it is created but not cleaned up.

This works with all julia versions.
Though because it accesses internals of Pkg it is very fragile to changes in Pkg – almost ever single minor release of julia breaks this.
So we have not yet tagged a release off the (currently working) release-1.8 branch.

My own plan is to add this to my global environment and probably to my startup.jl

31 Likes
2

Sorry for naive question, but if (when?) 1.6 is declared as LTS, this package will be less useful, since developers can switch to support 1.6+?

And thank you for development of TestEnv.jl, supporting 1.0 is not so easy now, so it is definitely helpful.

3

Less useful, yes. But still useful.
For a few reasons:

  1. some will keep supporting 1.0 forever (not many but some)
  2. some prefer the [extras] over the separate Project.toml (I know I do, as otherwise it is too easy to lost track and mistakenly install things both as main and test deps, and potentially with conflicting compat)
  3. The way to activate via hacking on your LOAD_PATH is kinda undocumented and people run into issues with it. See that thread. TestEnv uses a different mechanism that is basically what Pkg.test uses.
  4. TestEnv.activate() is nicer and easier to write than push!(Base.LOAD_PATH, joinpath(dirname(Base.active_project()), "test"))

But yeah, if using the LOAD_PATH way works for you and you are happy with it, then absolutely no reason to use TestEnv. :v:

5 Likes
4

Does TestEnv also work in the test/Project.toml scenario?

5

Yes.

1 Like
6

Thank you so much for this!

7

I currently help myself with an ugly shell script that does the LOAD_PATH hacking - TestEnv.activate() is so much cleaner.

8

@davidanthoff would it be possible to support something like this in the VS code Julia plugin, in the environment selector? So that the language server also switches to the test environment?

2 Likes