https://pantsbuild.org/ logo
#development
Title
# development
s

sparse-lifeguard-95737

11/01/2022, 8:17 PM
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

witty-crayon-22786

11/01/2022, 8:22 PM
cc @curved-television-6568
c

curved-television-6568

11/01/2022, 8:26 PM
@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

sparse-lifeguard-95737

11/01/2022, 8:31 PM
hrm… that is what I meant, I’m surprised to see the entry in the pants repo
c

curved-television-6568

11/01/2022, 8:31 PM
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

sparse-lifeguard-95737

11/01/2022, 8:31 PM
let me double-check locally (I’ve only seen the error in CI so far)
c

curved-television-6568

11/01/2022, 8:32 PM
If the above, then it may be a variant of https://github.com/pantsbuild/pants/pull/17365 you’ve hit
👀 1
s

sparse-lifeguard-95737

11/01/2022, 8:40 PM
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

curved-television-6568

11/01/2022, 9:41 PM
Ah, wait, you need a BUILD file in the same path as the lockfile in order for the synth target to show up
s

sparse-lifeguard-95737

11/01/2022, 9:52 PM
🤔 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

happy-kitchen-89482

11/01/2022, 9:57 PM
We definitely don’t want peek to have dependencies pointing to targets that aren’t listed …
c

curved-television-6568

11/01/2022, 9:59 PM
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

sparse-lifeguard-95737

11/01/2022, 10:18 PM
Thanks!
c

curved-television-6568

11/03/2022, 1:10 AM
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)