How do I activate the test environment of a package?

Tooling Package Management
1

I want to do some testing of changes to a package I’ve deved. I activate the package environment, but it doesn’t have some imported packages I want to use during testing. (For concreteness, I’m working on ModelingToolkit and I want to use OrdinaryDiffEq.) Now, I see that there’s a test target in the package’s Project.toml which includes OrdinaryDiffEq.

I tried activate test but I got:

(ModelingToolkit) pkg> activate test
  Activating new project at `C:\Users\lucas\Documents\Code\Jdev\ModelingToolkit\test`

which is not what I intended. What should I be doing instead? I don’t think I should be adding OrdinaryDiffEq to the base environment of ModelingToolkit here. (First of all, it’s not meant to be a dependency, and second, IDK if I’ll get the right version number.)

2

Try GitHub - JuliaTesting/TestEnv.jl: Activate your test enviroment, so you can use your test dependencies in the REPL

Not perfect (because you need one more package), but works for me…

1 Like
3

My workaround is to

  1. activate the test environment,

  2. put .. in LOAD_PATH.

I have utility functions for this in my startup file. It is kind of a hack, but it works.

function put_in_load_path!(dir = "..", pos = 2)
    if dir ∈ LOAD_PATH
        @warn "$(dir) is already in LOAD_PATH"
    else
        insert!(LOAD_PATH, pos, dir)
    end
    LOAD_PATH
end

function del_in_load_path!(dir = "..")
    pos = findfirst(isequal(dir), LOAD_PATH)
    if pos ≡ nothing
        @warn "$(dir) is not in LOAD_PATH"
    else
        deleteat!(LOAD_PATH, pos)
    end
    LOAD_PATH
end
4

Yup, this is the winner for sure, and doesn’t require any non-dev tool packages in your global environment. How to use VSCode and REPL to write and test a package? - #4 by jlperla writes up what I found to be the easiest workflow. If a package doesn’t have a test/Project.toml but has it embedded in the main Project file, I think TestEnv is still supposed to work.

1 Like
5

Yes, it works for both cases

2 Likes
6

I have a question on this workflow, if I may.

I’m new to Julia and still trying to get a feel for a preferred workflow. So far, I have found I can:

  • Keep my projects in ~/.julia/dev, which is done automatically when using PkgTemplates
  • Use project=true while creating my project, so that there is a Project.toml file in ./test
  • While in the global environment, use ] dev MyPackage so that my code is reachable from the test environment via stacking
  • In vscode, have the repl activate the test environment, and then use TDD from there

From my (limited) testing, it seems the language server in vscode can stay in the project environment, providing completions, etc.

So far, I’ve been able to write tests, modify code to make them pass, with the use of Revise.jl by the vscode extension making it pretty seamless.

What I’d like to know is if I’m missing something here (I suspect I am), and in what ways this workflow differs from the TestEnv method, or if it is mainly equivalent and just a matter of preference.

1 Like