I wonder if we can avoid hardcoding the path to the Manifest and rely on julia itself. For example, pkgdir(ClimaCore) would tell us. I don't know if Pkg has some functions to inpect a project without instantiating it

Also, we should avoid continuing the bulid if this check fails.

Unfortunately, pkgdir(ClimaCore) requires loading (and precompileing ClimaCore), which is why I went with just using TOML like this. It's ugly, but much more lightweight.

Yes, I was wondering if Pkg had some way to probe the environment programmatically without instanting it. I mean, it has to do it to instantiate up the env in the first place, but I don't know if this is somehow exposed to the user.

Alternatively, a slightly cleaner julia one liner would be:

using TOML; @assert TOML.parsefile(".buildkite/Manifest.toml")["deps"]["ClimaCore"][1]["path"] == ".."

This is to for N manifests:

using TOML; for f in filter(x->startswith("Manifest",x), readdir(".buildkite")); @assert TOML.parsefile(joinpath(".buildkite",f))["deps"]["ClimaCore"][1]["path"] == ".."; end

Yes, I was wondering if Pkg had some way to probe the environment programmatically without instanting it.

I didn't see anything from a quick look through Pkg.<tab>. Another option, just using Pkg would be to Pkg.develop(".") and then check if the manifest has changed (via git).

I like using TOML; @assert TOML.parsefile(".buildkite/Manifest.toml")["deps"]["ClimaCore"][1]["path"] == "..", want to move forward with that?

A quick look seems to indicate that Pkg.dependencies()[UUID("d414da3d-4745-48bb-8d80-42e94e092884")].source is ClimaCore's path in this environment.

We can probably clean this up to avoid hardcoding the uuid and use the name instead

I kind of like that using TOML; @assert TOML.parsefile(".buildkite/Manifest.toml")["deps"]["ClimaCore"][1]["path"] == ".." is explicitly looking at the manifest file. The Pkg.dependencies business requires us to look into the implementation to see where it's getting that from. Also:

  Pkg.dependencies()::Dict{UUID, PackageInfo}

  This feature is considered experimental.

I think the strength of using Pkg is that we are guaranteed to access the same information that the julia is using in instantiating the environment.

Pkg.dependencies().source is part of the documented API of this function, so I don't think that this is looking into the implementation.

Actually, looking at the documentation, I see that there's directly a field isdeveloped to check what we want to check

    Pkg.dependencies()::Dict{UUID, PackageInfo}
Query the dependecy graph.
The result is a `Dict` that maps a package UUID to a `PackageInfo` struct representing the dependency (a package).
PackageInfo fields:
| `field`        | `Description`                                              |
|:---------------|:-----------------------------------------------------------|
| `name`         | The name of the package                                    |
| `version`      | The version of the package (this is `Nothing` for stdlibs) |
| `isdeveloped`  | Whether a package is directly tracking a directory         |
| `ispinned`     | Whether a package is pinned                                |
| `source`       | The directory containing the source code for that package  |
| `dependencies` | The dependencies of that package as a vector of UUIDs      |

So the test could be

using Pkg; @assert Pkg.dependencies()[Base.UUID("d414da3d-4745-48bb-8d80-42e94e092884")].isdeveloped

This feature is considered experimental.

This feature was introduced in julia 1.4 and has not changed at all since then. I opened an issue to Pkg to ask why they are still considered experimental.

All of this said, I don't feel strongly about this. I think that the benefits compared to manually parsing the file are more theoretical than practical, so I am happy to go with the other solution too. I'll leave it up to you.