not sure if bug or by design: on 2.15.0a0, the out...
# development
s
not sure if bug or by design: on 2.15.0a0, the output of
./pants peek ::
has changed because of synthetic lockfile targets 🧵
👀 1
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
☝️ 1
👀 1
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
w
cc @curved-television-6568
c
@sparse-lifeguard-95737 what do you mean with top-level entries? What is missing?
I’m looking in the pants repo, and here I see this example:
Copy code
{
    "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:
Copy code
{
  "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
}
👀 1
s
hrm… that is what I meant, I’m surprised to see the entry in the pants repo
c
is by chance your python requirements target and the resolve sharing the same name and the lockfile and requirements.txt file the same path?
s
let me double-check locally (I’ve only seen the error in CI so far)
c
If the above, then it may be a variant of https://github.com/pantsbuild/pants/pull/17365 you’ve hit
👀 1
s
confirmed that I don’t see any entries for our lockfiles when running peek locally
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:
Copy code
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
c
Ah, wait, you need a BUILD file in the same path as the lockfile in order for the synth target to show up
s
🤔 is it a bug then that the lockfiles are showing as dependencies in the peek output even though there are no BUILD files?
Is that the linked issue?
h
We definitely don’t want peek to have dependencies pointing to targets that aren’t listed …
c
That is not the linked issue. I’ll open a new one for this.
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.
s
Thanks!
c
Fix under way: https://github.com/pantsbuild/pants/pull/17451. still needs some tests (I managed to solve the latter per above, which is great as I failed in my previous attempts at that)