https://pantsbuild.org/ logo
Join Slack
Powered by
Has anyone thought about `package` support for `ad...
# development
g
Has anyone thought about 
package
support for 
adhoc_tool
? Doesn't seem to exist in 2.16 or 2.17 at least, and nothing on GitHub matches. It seems like one can ish get that to work with 
experimental_wrap_as_resources
+ 
export-codegen
but it seems a bit roundabout.
I think it might require some extra target still; something like 
adhoc_package
? As I think goals cannot conditionally apply on target (i.e., adhoc_tool is packageable iff...).
b
archive
sort of works as a workaround for this purpose, although isn’t perfect (eg if outputting the files directly is what’s wanted, rather than zipping them up) https://github.com/pantsbuild/pants/issues/17729 is somewhat related
g
Yeah; I've tried archive as well. It's a bit inconvenient because it also requires me to use 
relocated_files
in that case. And I still need 
experimental_wrap_as_resources
to put them into a pex for dev workflows.
It's a bit of a mouthful here...
Copy code
adhoc_tool(
    name="build",
    runnable=":bin",
    args=["generate", "content"],
    execution_dependencies=["//content:files", "//templates:files"],
    output_directories=["public"],
    timeout=300,
    workdir="/",
)

relocated_files(
    name="rooted",
    files_targets=[":build"],
    src="public",
    dest="",
)

archive(
    name="archive",
    format="tar.gz",
    files=[":rooted"],
)

experimental_wrap_as_resources(
    name="site",
    inputs=[":build"],
)

pex_binary(
    name="serve",
    entry_point="http.server",
    args=["-d", "{chroot}/cmd/serve.pex/public"],
    dependencies=[
        ":site",
    ],
    execution_mode="venv",
    layout="loose",
    restartable=True,
)
👍 1
b
The shell command stabilisation / adhoc tool addition added a new field (root output directory , or something) that hopefully removes the need for relocated files in many cases (on my phone, so sorry for the lack of details)
(But, yes, it’s definitely not a smooth process. Especially the files vs resources split, at the moment)
g
I think that is a generic pain point, yeah. Very hard to generate files for arbitrary other things... what if I want an adhoc_tool generating 
.md
files for an mdbook integration, f.ex. -- now that needs 
experimental_wrap_as_md
, but that's likely the md of my mdbook plugin... if someone else has a MarkdownSource type that is likely to be different. 🤯
Works fine as long as plugins are built in the pants repo; but for external plugins it becomes... unwieldy.
b
FWIW I don't think the "wrap" targets are going to stay, since they're all hand curated. We should have a mechanism for it
h
The mouthful could be macro'd up
If it turns out to be a repeated pattern
g
True. Though I don't think it's a repeated pattern "per repo" but definitely unergonomic across many use-cases of 
adhoc_tools
.
h
Yeah not claiming that solves the issue, but maybe mitigates it temporarily
Open in Slack
PreviousNext
Powered by