broad-processor-92400
09/28/2022, 1:44 AMbuild_docker_image
rule and feeding it through https://github.com/pantsbuild/pants/blob/c5e902e6a630495c17e234012c001ed4f97b4173/src/python/pants/backend/docker/goals/package_image.py#L335 to set relpath
... but I'm not sure of the right way to do this.
3. Once there's a schema and I know how to create a file, what's best way to actually create the JSON output? In our app, I'd define pydantic models and let pydantic handle the serialisation, rather than build dicts manually; is there something similar available in pants?happy-kitchen-89482
09/28/2022, 5:59 PMversion: 1
at the top level and no need to think about it until we need to change it…dist
needs to happen on every run (the thing that is written out can be cached) as it is a requested side effectcurved-television-6568
09/28/2022, 6:23 PMdataclasses.todict()
on an instance of that../pants publish
there is structured output available already: https://www.pantsbuild.org/docs/reference-publish#outputpackage
goal, then perhaps make it in the manner as for publish
, so that each implementation can add their specific data to it. It also ensures that it gets written every time without invalidating the cache of the package/publish rule.
https://github.com/pantsbuild/pants/blob/cdf21fc69954aec999ed57ed988bf67a31148bf9/src/python/pants/backend/docker/goals/publish.py#L42
https://github.com/pantsbuild/pants/blob/cdf21fc69954aec999ed57ed988bf67a31148bf9/src/python/pants/core/goals/publish.py#L138-L145
https://github.com/pantsbuild/pants/blob/cdf21fc69954aec999ed57ed988bf67a31148bf9/src/python/pants/core/goals/publish.py#L279-L284broad-processor-92400
09/28/2022, 11:35 PMdataclasses
directly sounds good.
In terms of implementation, my impression is that publish --output
works well for something orchestrating pants (e.g. a CI script or interactively), but I think this output would be useful within pants, such as a test target wanting to use a docker image in runtime_package_dependencies=[...]
, or feeding into a deploy template synthesised within pants.
I think this means it'd be useful as part of ./pants package
output, and also that it can't just be ./pants package --output whatever.json
.
Do I misunderstand?curved-television-6568
09/29/2022, 1:25 PMBuiltPackage.get_output_data()
(or whatever the method should be called), so it’s accessible to rules/plugins as well without extra effort.broad-processor-92400
09/29/2022, 10:24 PMruntime_package_dependencies=[...]
?curved-television-6568
09/29/2022, 10:44 PMbroad-processor-92400
09/29/2022, 11:02 PMshunit2_test
or python_test
to be able to access the docker image (to run it, and/or run some sort of introspection on it)
2. local development commands like starting a set of images via docker-compose (could be orchestrated via experimental_run_shell_command
)
3. infrastructure-as-code able to access this to generate a CloudFormation template or similar (could be a ./pants run path/to/template_generator.py
, for instance)
When an executable is packaged as a pex, it seems to be easy enough to depend on it via existing pants mechanisms. and it's be more than a bit annoying for executables that happen to be packaged via docker to require a custom plugin/rule.
The original discussion talked about putting this info into dist/
like any other packaged artefact (which is a mechanism we're already using for other things, like pex executables and lambda zip packages), whereas this new mechanism I don't understand yet, hence asking questions to try to double check it satisfies what I hope it might 😄curved-television-6568
09/29/2022, 11:56 PMdist/..
so that may be used as a file/resource input digest for dependees of that target.broad-processor-92400
10/20/2022, 9:37 PM