https://pantsbuild.org/ logo
Join Slack
Powered by
Is there a goal or flag that I can pass to `pants ...
# general
b
Is there a goal or flag that I can pass to 
pants package <target>
that will print out the dest path without creating the package? I'm trying to integrate 
pants
into a workflow that needs to know where things land before running the package step.
I was hoping for a flag like 
pants package <target> --output-path
or that I could extract it from 
pants peek
but that only gave me the template: 
"output_path": "${spec_path_normalized}/${target_name_normalized}${file_suffix}"
In case I missed it in the docs and it's just a funneling issue, I checked the following:
Copy code
# hopefully there's an option to dry-run?
pants help-advanced package

# maybe there's a global dry-run for all goals?
pants help-advanced global

# maybe I can just pass --from=<package target> and it knows I want the output destination since it's a package?
pants help-advanced paths
command line help: https://www.pantsbuild.org/stable/docs/using-pants/command-line-help project introspection: https://www.pantsbuild.org/stable/docs/using-pants/project-introspection
w
Is there anything that can be useful coming out of 
peek
?
I don't know if the relative dist paths get resolved in there or not
f
They aren't resolved there. They are resolved when artifacts are about to be written out as that is when 
value_or_default
is actually called. https://github.com/pantsbuild/pants/blob/40a1e07b1a92c3220847d97bcdfbd4d7fab9a6b6/src/python/pants/core/goals/package.py#L123
That field subclasses 
AsyncFieldMixin
. An improvement to 
pants peek
would be for it to understand all of the fields which subclass 
AsyncFieldMixin
and know how to ask for their finalized values.
(since this issue is not unique to 
output_path
)
w
So, not that it's a great option - but if the user enters 
output_path
, it is emitted (but not resolved... e.g. when I update it in the BUILD, it is peeked out with the same value). But, the way we make default output paths is deterministic - so a janky way would be to manually re-do some of that logic 🤮
Peek is generally a good start for automation - however, a dry-run might be interesting 🤷 Not sure how I feel about that
My concern putting it in peek is whether/how much we'd get perf hit on every field needing to go back through the engine (as I think that's where it's resolved). Would be worth a test
f
It wouldn't need to be every field. Just those where 
issubclass(field, AsyncFieldMixin)
is true. Or maybe we have a union 
ResolveFieldForPeek
which 
peek
can use so backends can register which fields should get special treatment.
The non-hacky way would be to improve the 
peek
goal to know how to do such things.
b
I was looking through the package.py goal, for exactly that reason 🙂 For others, here's what I'm getting back from 
peek
and the build target used.
Copy code
$ pants peek src/lambdas/widget:lambda
[
  {
    "address": "src/lambdas/widget:lambda",
    "target_type": "python_aws_lambda_function",
    "architecture": "x86_64",
    "complete_platforms": null,
    "dependencies": [
      "src/py/corp/widget/entrypoint.py"
    ],
    "dependencies_raw": null,
    "description": null,
    "environment": "__local__",
    "goals": [
      "package"
    ],
    "handler": "corp.widget.entrypoint:lambda_handler",
    "include_requirements": true,
    "layout": "flat-zipped",
    "output_path": "${spec_path_normalized}/${target_name_normalized}${file_suffix}",
    "pex3_venv_create_extra_args": [],
    "pex_build_extra_args": [],
    "resolve": null,
    "runtime": "python3.13",
    "tags": null
  }
]
and using this BUILD:
Copy code
python_aws_lambda_function(
    name="lambda",
    handler="corp.widget.entrypoint:lambda_handler",
    runtime="python3.13",
)
f
Maybe open a feature request to capture the ask?
b
peek as it is today feels like a good speed/detail balance; adding things like baked output paths might be too expensive (or open the floodgates). In fact, I almost have enough from the peek output to calculate it myself - I just need to know how pants wants to calculate 
spec_path_normalized
etc. Is there something like a 
peek
for the global context that pants runs in?
That would keep a nice split of (peek: what this target does) and (global: where pants is rendering things to) and let the user choose the perf hit.
f
spec_path_normalized
is just replacing the BUILD file's directory separators with 
.
"spec path" is just the directory
b
right, but that's relative to the build root, which I won't know from where this tool is running. I'll see if I can distill this to a useful feature request. Thanks for the pointers in the meantime!
3 Views
Open in Slack
PreviousNext
Powered by