Hey! I'm upgrading a plugin to run with 2.14 inste...
# development
g
Hey! I'm upgrading a plugin to run with 2.14 instead of 2.13 and I think I've found a bug/regression/undocumented change(?); but figured I might post here before filing an issue (can't find any so far). The repro is in my OCI backend, and it's very trivial:
Copy code
raw_layer_digest = await Get(Digest, CreateArchive(snapshot, "image_bundle.tar", "tar"))
Where snapshot is:
Copy code
Snapshot(digest=(6ef63a638db36f100b2a48fb7b1b497131ef2551d2d4c6251882fb631b458820, 82), dirs=(examples), files=(examples/example.pex))
On 2.13 this works fine, and on 2.14 it crashes with the following:
Copy code
15:00:12.12 [ERROR] 1 Exception encountered:

Engine traceback:
  in select
  in pants.core.goals.package.package_asset
  in pants_backend_oci.goals.package.package_oci_image (examples:oci)
  in pants_backend_oci.util_rules.build_image_bundle.build_oci_bundle_package
  in pants.core.util_rules.archive.create_archive
Traceback (no traceback):
  <pants native internals>
Exception: Path `` was unexpectedly empty
Whatever the changes happened between 2.13.0 and 2.14.0rc0. It all works as expected if I set
output_filename
to have a directory component. After digging a bit I believe this might be a Rust change somewhere; potentially from this line/change: https://github.com/pantsbuild/pants/pull/16648/files#diff-78b61c9a9b42b3895a2c71b90e31aceee5a5f38780edddbd4daec17ee4386d98R475.
I think the real bug is actually in the CreateArchive rule assuming that the output goes into a directory and thus not checking whether
os.path.dirname
is valid.
I can patch this to not create the dir if not wanted, but I'm wondering whether the CreateArchive rule should require a dirname?
output_filename
quite strongly suggest a filename and not a path... 😛
h
Thanks for the debugging and the fix! We’ll take a look tomorrow 🙂
❤️ 1
Meanwhile I’ve labeled the PR and triggered a CI run