also thinking of <https://github.com/pantsbuild/pa...
# developmentc
careful-address-89803
05/29/2024, 6:42 PMalso thinking of https://github.com/pantsbuild/pants/issues/20718 (dockerfile COPY of targets), does someone know why we use the output path of the target instead of the target address?
That is, why
COPY project.hello.main.py/main_binary.pex /entrypointCOPY project/hello/main/py:main_binary /entrypointb
broad-processor-92400
05/29/2024, 6:53 PMI think the principle is that pants doesn’t edit the dockerfile. the output path/artifact path is how the target will end up in the docker build context so that’s what needs to appear literally in the file contents
c
careful-address-89803
05/29/2024, 7:05 PMah, that makes sense. Would we consider changing that? Would we think differently about "rewriting" by passing in and arg? eg
Copy code
FROM python:3.12
ARG PEX_BIN=/foo/bar/baz:hello
COPY ${PEX_BIN} /app/hello.pexb
broad-processor-92400
05/29/2024, 7:28 PMSupporting args for this sounds reasonable to me, but I’m a bit unclear on all the moving parts.
c
careful-address-89803
05/30/2024, 1:55 AMI think it's 2 steps:
1. follow COPY args to their definition (same as for values of FROM)
2. if it is a valid target, get it's output path (we use the output path for the existing inference, but in reverse) and pass that in as an ARG
I've got 1 working, and I think 2 is mostly plumbing
careful-address-89803
05/30/2024, 5:48 AMok, uh, how bad would it be if we couldn't distinguish between output files which have the same filename except for their file extension? ex we could not distinguish "app.pex" from "app.zip"
turns out the output path doesn't include the file extension. The existing implementation uses the output path specified by the user, which includes the expected file extension. But I think that's added by the backend itself when writing the file out...
b
broad-processor-92400
05/30/2024, 5:57 AMAre there other backends that do similar inference of build artefact names? (Maybe in shell scripts?)
If they have the same limitation, seems reasonable to not feel forced into fixing a pre-existing bug to me!
c
curved-television-6568
05/30/2024, 11:48 AMyea, the COPY dep inference pre-dates the FROM arg support for upstream images. I'm +1 for supporting a target based syntax via build ARGs. The reason for using the artefacts file name is as Huon says, that's the name it gets in the docker build context in the sandbox.
c
careful-address-89803
06/02/2024, 3:13 AMactually it occurs to me that for the COPY we shouldn't use the output path, we should use the files in the actual digest
c
curved-television-6568
06/02/2024, 6:28 AMA) what’s the difference, and b) we use the path from COPY to infer deps to package into the build context; so if you look in the actual build context how do you know what to package?
4 Views