Strange behaviour of quickactivate when using explicit test project

[henrik-wolf]

I recently had a strange run-in with @quickactivate in a new DrWatson project I am working on, where it does not activate the project with the given name, but rather the first project that it comes across, starting from the directory of the executed file. My project structure looks somewhat like this:

MyProject
|  src
|  |  MyProject.jl
|  Project.toml  # defining the MyProject package
|  test
|  |  Project.toml  # defining the Test dependencies
|  |  current.jl
|  |  runtests.jl
...

I am using the current.jl file, located in the test folder, as some kind of scratchspace to prototype every functionality that I eventually integrate into the package, tests, scripts and so on. This file starts with

using DrWatson
@quickactivate :MyProject

# some throwaway code

Executing the first two lines in this file, I would expect it to search for, find and activate the project with the given file (in this case at MyProject/Project.toml). However, because current.jl is located in the test folder, it finds the MyProject/test/Project.toml file, activates it, and then throws an error:

  Activating project at `~/MyProject/test`
ERROR: The activated project did not match asserted name. Current project name is nothing while the asserted name is MyProject.

(reexecuting the @quickactivate :MyProject then just silently fails, not rethrowing the error.)

Intuitively, I would expect it to keep searching upwards until it finds a project with the given name to activate, and to fail if there is none, without changing the currently activated project (I know that this is documented, however it is still unintuitive behaviour to me).

I realise that changing this behaviour is probably breaking in many ways, but maybe there could be a keyword added to @quickactivate such as

# only activates the project if the name matches
@quickactivate : MyProject matchonly=true

@quickactivate :MyProject matchonly=false
# same as
@quickactivate :MyProject

or another macro

@quickactivate_matched :MyProject

[Datseris]

However, because current.jl is located in the test folder, it finds the MyProject/test/Project.toml file, activates it, and then throws an error:

Activating project at ~/MyProject/test
ERROR: The activated project did not match asserted name. Current project name is nothing while the asserted name is MyProject.

(reexecuting the @quickactivate :MyProject then just silently fails, not rethrowing the error.)

This is the correct and expected behaviour. This is explained in the quickactivate documentation string. The function will find the first Project.toml file and activate it. It will then throw an error if it doesnt match the provided name. That's exactly what you get.

I don't remember exactly why it first activates and then throws an error. I think it wasn't possible to do it the other way around. By now the Pkg manager has improved drastically so it may be possible to error before activation.

The second run you run @quickactivate it doesn't fail; it simnply does nothing as the function will not activate the same project twice (I think this is also stated in the docstring? not sure)