Unresolved envs in LOAD_PATH prevent PythonCall from being loaded

[MichaelHatherly]

If there are any environments in the LOAD_PATH that haven't yet been resolved then an error is thrown when the call to Pkg.dependencies() is made.

The line referenced below calls Pkg.dependencies():

CondaPkg.jl/src/resolve.jl

Line 184 in 99d4053

for env in [proj; [p.source for p in values(Pkg.dependencies())]]

@cjdoris would it make sense to guard that call based on whether the environment has been resolved or not?

Related to that, on the line above:

CondaPkg.jl/src/resolve.jl

Line 183 in 99d4053

Pkg.activate(proj; io = devnull)

each environment is Pkg.activated prior to calling Pkg.dependencies(). There is a method of dependencies that takes an EnvCache so it's not (I believe) required to activate everything in the load path for the operation that that code is doing.

I'm happy to take a look at making the fix if you're alright with the proposed changes?

---

This came up in PumasAI/QuartoNotebookRunner.jl#256 (comment). We are now using PythonCall to support having Python cells in our Quarto backend. Thanks for making that possible with your work here!

[cjdoris]

Hmmmm ok interesting!

Presumably by unresolved you mean there is no Manifest.toml, or it exists and is out of date?

It's not totally obvious. I suppose that since we cannot read the dependencies this way, our two options are either to error or to ignore such a project.

Given it might be some project lower down the load path that isn't even being used, ignoring it seems to be ok? We should probably at least log a warning in this case.

As for avoiding needing to activate the project, if there is a better faster way, be my guest. Is EnvCache API or internal?