within the

peek

output, lockfile targets appear in the

dependencies

arrays of other targets, but they don’t have their own top-level “entries” in the peek JSON

this makes sense to me conceptually, but it does break the previous invariant that every dependency listed for a target would have its own object in the

peek

output

we have a program that consumes

./pants peek ::

to build and analyze our dependency graph, which broke because of the change

was easy to fix (ignore cases where a

dependency

doesn’t have its own entry) but might be a common paper-cut as people upgrade

I’m looking in the pants repo, and here I see this example:

{
    "address": "3rdparty/python#uvicorn",
    "target_type": "python_requirement",
    "dependencies": [
      "3rdparty/python/requirements.txt",
      "3rdparty/python/user_reqs.lock:python-default"
    ],
    "dependencies_raw": [
      "3rdparty/python/requirements.txt",
      "3rdparty/python/user_reqs.lock:python-default"
    ],
    "description": null,
    "modules": null,
    "requirements": [
      "uvicorn[standard]==0.17.6"
    ],
    "resolve": null,
    "tags": null,
    "type_stub_modules": null
  },

And the lockfile it refers to here, exists as it’s own entry:

{
  "address": "3rdparty/python/user_reqs.lock:python-default",
  "target_type": "_lockfile",
  "dependencies": [],
  "dependencies_raw": null,
  "description": null,
  "source_raw": "user_reqs.lock",
  "sources": [
    "3rdparty/python/user_reqs.lock"
  ],
  "tags": null
}

and no, we have a nameless

python_requirements

in

3rdparty/BUILD.pants

that maps to our

default

resolve. the

default

resolve’s lock is at

3rdparty/lockfiles/resolves/default.lockfile

hmmmm though, for our non-default resolves we do have a pattern like:

3rdparty/<resolve-name>/BUILD.pants

and then a nameless

python_requirement

or

python_requirements

in the BUILD dir, so we might get a naming collision there? but the lockfiles are always in a separate directory

Is that the linked issue?

It’s a bit terse as I wasn’t sure how to properly describe this, but I have a good sense of what the issue is.

tweaked the wording slightly, as I think that the end goal is that synthetic targets must show up. One way is to ensure that they are only created in paths where there are BUILD files, another is to expand the known address families to also include paths with synthetic targets, even if there isn’t any other targets there.

The latter would be preferable, I believe, but also slightly trickier to achieve.

Will look into it asap.