How would one go about - having `pants package` a...
# plugins
a
How would one go about • having
pants package
also package the dependencies for a given field-set • creating a 'manifest' for all targets who did something as a result of
pants package
? I've got
pants package
generating the files I need to deploy "a widget" using some union rules (those are neat). But those things also depend on other "widgets". And then I need to create a manifest file of all the widgets packaged. Or am I going to have to create a custom goal command to do this?
h
can you share more what you mean with the first point? Might it be similar to the
archive
target type, which first builds other packes like
pex_binary
and then includes them? https://github.com/pantsbuild/pants/blob/a07ff036568970b7524637ef2c0247c7c91f9f8e/src/python/pants/core/target_types.py#L458-L481
re the manifest, so far the plugin hook only lets each target return whatever it wants: no mechanism to create something that belongs to multiple targets But I wonder if you can have
my_aggregating_target_type
exist, which will build all the packages you say it should and create a single manifest for those all. That should work
c
Just adding a mental note, that we have something similar to the manifest for the
publish
goal..
👀 1
a
@hundreds-father-404 so I've implemented a generic
SystemResource
target that
package
will generate a YAML file (aka 'a resource') for. In theory, you can deploy these resources individually. But there's sometimes non-enforced (by the platform) dependencies on other resources. The deployment utility that
pants publish
will call to deploy these resources works off a manifest file (more yaml!) that references all of the different resources to deploy (atomically?) in one go. So this manifest needs to be generated, as well as the packages for the individual resources, and all the transitive dependencies need to be packaged too Then there's also tests which run on the system directly, so (next steps) I'm going to need to make
pants test
1) find the all the dependent SystemResource targets, 2) package them 3) generate a manifest for them 4) publish them 5) test them
I guess I could make my package rule get the transitive dependencies, and then request the BuiltPackage for the transitive dependencies. Then rely on the caching to not 'double-package' things