test/Project.toml

Tooling Package Management
1

Using Julia 1.4.1, I added StaticArrays as a dependency to my project using add StaticArrays within Pkg mode. This generated an entry in Project.toml. But when I run test within Pkg mode, I get a load error saying that StaticArrays is not found in the current path. To fix this, I had to activate ./test and add StaticArrays again, which added an entry in test/Project.toml. Is this as expected? I thought test/Project.toml was for dependencies that are needed only during testing. In my case, StaticArrays is needed all the time.

It seems unfortunate that I have to add the dependency in both places, because this raises the possibility that I could be testing against one version of StaticArrays but using a different version the rest of the time.

Here is the main Project.toml:

name = "MatrixCoalescent"
uuid = "e18d61ee-b49e-4354-8047-cdb896e4a8a0"
authors = ["Alan R. Rogers <rogers@anthro.utah.edu> and contributors"]
version = "0.1.0"

[deps]
StaticArrays = "90137ffa-7385-5640-81b9-e52037218182"

[compat]
julia = "1"

[extras]
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"

[targets]

Here is test/Project.toml:

[deps]
StaticArrays = "90137ffa-7385-5640-81b9-e52037218182"
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
3 Likes
2

if from the project directory you do

Pkg.activate("test")
Pkg.dev(".")

Does it fix it for you?

I’ve run into problems with exactly this, so I’m not so sure that this is a solution for you, or the right pattern generally.

3

Wouldn’t that make a copy of my project in .julia/dev? I’ve never used dev before and don’t fully understand what it would do in a case like this, where I’m already in a development directory in which I can edit the code.

4

No, it shouldn’t do that.

(@v1.4) pkg> ?dev
  develop [--shared|--local] pkg[=uuid] ...

  Make a package available for development. If pkg is an existing local path, that path will be recorded in the manifest and used. Otherwise, a full git clone of pkg is
  made.
5

I didn’t work. I’m not sure what I’ve done.

(@v1.4) pkg> activate .
 Activating environment at `~/src/MatrixCoalescent/Project.toml`

(MatrixCoalescent) pkg> activate test
 Activating environment at `~/src/MatrixCoalescent/test/Project.toml`

(test) pkg> dev .
[ Info: Resolving package identifier `.` as a directory at `~/src/MatrixCoalescent`.
Path `.` exists and looks like the correct package. Using existing path.
  Resolving package versions...
   Updating `~/src/MatrixCoalescent/test/Project.toml`
  [e18d61ee] + MatrixCoalescent v0.1.0 [`..`]
   Updating `~/src/MatrixCoalescent/test/Manifest.toml`
  [e18d61ee] + MatrixCoalescent v0.1.0 [`..`]

(test) pkg> test
ERROR: trying to test unnamed project

(test) pkg> activate .
 Activating environment at `~/src/MatrixCoalescent/Project.toml`
 
(MatrixCoalescent) pkg> test
    Testing MatrixCoalescent
ERROR: can not merge projects
6

What does your runtests.jl file look like? If you have a using StaticArrays in it, then you need to have the package loaded in the test environment.

7

Also, you can look at Reexport.jl to do @reexport using StaticArrays in your module code. If you truly always need StaticArrays this is probably the better plan.

8

Here is runtests.jl:

using MatrixCoalescent
using Test

include("LTriMatrix.jl")

LTriMatrix.jl begins with:

using Test
include("../src/LTriMatrix.jl")

and …/src/LTriMatrix.jl begins with:

using StaticArrays

So the test always uses StaticArrays. That dependency is listed in the main Project.toml. It surprises me that I need also to list it in test/Project.toml.

9

Had a look at Reexport.jl, and I suspect it is more than I need. I’m trying to do something very simple: write a unit test (in the test directory) for a file (in the src directory) that has a dependency. Surely Julia can handle that without the need for an external library. No?

Thanks, Alan

10

That is the same as what I said. So StaticArrays must be in the test environment. If you have to do using MatrixCoalescent, StaticArrays in order to get the functionality you want, then StaticArrays must also be in whatever environment you are operating in, even if it is also included in the Project.toml for MatrixCoalescent. In this scenario, it isn’t just a package dependency because you are explicitly using it. For example, if your package also depends on StatsBase, but only for internal functions and nothing from StatsBase directly shows up in your tests, then you don’t need to add StatsBase in test/Project.toml.

The test environment is just like any other environment at this point. So you have to bring into that environment what you plan to use.

2 Likes
11

This is the correct answer, but it’s a bit unsatisfying for precisely the reason laid out in the OP

One way around this that I’ve found is that you can actually do using MatrixCoalescent.StaticArrays in your test file (not 100% sure, but you may have to do this after using MatrixCoalescent).

3 Likes
12

Thanks to you all.

1 Like