Open Roger-luo opened 2 years ago
I've never fully worked out how exactly it activate
works. But I agree, supporting a path would be good.
Here is another motivation to support paths. The recommended way to share a project between Pluto notebooks is
Pkg.activate(Base.current_project())
So it seems natural to replace that call with
begin
using TestEnv
base_project = Base.current_project()
Pkg.activate(base_project); # until Pluto knows that TestEnv.activate should disable Pluto pkg system
TestEnv.activate(base_project)
end
which currently fails with
TestEnv.TestEnvError("/path/to/package/Project.toml not installed 👻")
ctx_and_pkgspec(::String)@common.jl:24
activate(::String)@activate_set.jl:10
top-level scope@[Local: 5](http://localhost:1234/edit?id=fffa3cba-43f3-11ee-1d2b-db91fbb12088#)
removing the base_project
argument seems to work, so as a workaround:
begin
using TestEnv
base_project = Base.current_project()
Pkg.activate(base_project); # until Pluto knows that TestEnv.activate should disable Pluto pkg system
TestEnv.activate()
end
The issue was that Pkg.PackageSpec
is not as permissive as Pkg.activate
.
If passed a string as first argument, it has to be the name, not the path.
In other words, Pkg.PackageSpec
blindly put the path into the name
field.
Food for thoughts after a shallow analysis (feeling out of my league here),
as an alternative to #39 (which would not allow to use the same Pkg
syntax with TestEnv
, IIUC ?).
After a look into Pkg.activate
code, instead of trying to handle all these possibilities directly in TestEnv
,
I'd lean to do it in two passes:
1) Pkg.activate(arg...; kwargs...)
, minus those specific to TestEnv
of course.
2) Analyze this activated project and clone it to tmp, activate
this clone, flesh it out with test deps,
and only then instantiate.
pro: uses the regular activate
mechanisms to locate the package (so that part should work with any julia version).
con: two activate
instead of one (but it's super fast anyway, and there would be only one instantiate).
I think it would be much more convenient if one can pass a path instead of an available package name to create the test environment since
path
is a more straightforward concept that everyone understands, e.g in a hierarchical project like https://github.com/QuantumBFS/Yao.jl/ we have a lot of component packages live inlib
directory, and packages inlib
do not necessarily to be listed as a dependency in theProject.toml
of upper-level packages, which as a result usingname
will sayxxx
isn't installed. But I think it's reasonable to activate a random package locally from a shared environment that hasTestEnv
installed.