https://pantsbuild.org/ logo
Join Slack
Powered by
Been looking through the docs and mucking around f...
# general
p
Been looking through the docs and mucking around for awhile now, but I'm stuck. How do I get the 
.whl
file from a 
python_distribution
target into the build context for a 
docker_image
target? Or is this an anti-pattern? Works great for 
pex_binary
, but there is no 
output_path
argument for a 
python_distribution
. And how do I also enforce a dependency on a 
python_distribution
target in my 
docker_image
target?
👀 1
b
It should be doable, but idk if Pants can handle it today. Let me poke around at the code and find out tonight when I'm back at a desktop
FWIW I think this ties into a proposal im working on which should allow pants to be flexible enough to handle this.
h
I would have thought this would work today. I think all BuiltPackage instances are placed into the 
docker_image
build context. No, @curved-television-6568? The problem might be knowing what exact path it's at.
💯 1
b
FWIW I think inference works for anything with an output path field. I remember adding that
p
I worked around it with an 
archive
target that assembled the wheels built from all the 
python_distribution
targets I'm interesting in. 
archive
targets are available in the build context, so I just copy that into the image, unpack it, and install all the wheels it contains
So something like:
Copy code
archive(
    name="web-tarball",
    packages=[
        "src/python/org/services/silly_web_backend:silly_web_backend-dist",
        "src/python:org-libs"
    ],
    format="tar.gz"
)

docker_image(
    name="web_backend",
    dependencies=[
        ":msg",
        ":web-tarball",
        ":image_scripts"
    ]
)
Which means you have access to 
<http://path.to|path.to>.docker.target/web-tarball.tar.gz
in the build context
3 Views
Open in Slack
PreviousNext
Powered by