feat(#83): libarchive-backed archive reader as a standalone extra module - #437
Merged
Merged
Conversation
Second archive slice: the dependency and the reader, still with no walk integration. extra_modules/archive/ is its own Bazel module (@xff_archive), the same shape as the PCRE2 extra: it depends on @libarchive (from the BCR, no vendoring) and the shared @xff_extras_api seams, never back into the xff core, so deleting the directory drops the extra entirely. Verified: the lean //xff/cli:xff has zero libarchive in its dep graph. archive_reader lists an archive's members from memory or by streaming a file. libarchive detects the format and compression filter from content, so tar / zip / cpio / ar and the gz / bz2 / xz / zstd / lz4 filters all come through one entry point. It reads headers only, never member content, so listing a huge archive stays cheap. The error contract matters for the walk and is pinned by tests: "not an archive" (InvalidArgument) must stay distinct from "corrupt archive" (DataLoss) - the first is an ordinary file, the second is a real error to report. Empty input is explicitly not an archive: libarchive opens zero bytes and reports EOF, which would otherwise make an empty file look like a valid archive holding nothing. Licensing: libarchive is BSD-2-Clause and its codec closure (zlib, bzip2, liblzma, lz4, zstd on its BSD arm) is permissive throughout; mbedtls stays off, so no crypto arm is pulled. The notice registers itself from the reader's translation unit through the existing license-notice seam, so --help=notice and the NOTICE file stay complete by construction. Tests write real tar and gzip-filtered tar archives with libarchive's write API and read them back, so there are no committed binary fixtures and the whole dependency is exercised end to end.
Three more sites still printed or documented the non-existent flag: the help renderer's not-built note, the --archive flag's own details prose, and a BUILD comment. extras_test was pinning the wrong string, so it is corrected too (it asserted the bug rather than the behavior). All four surfaces now name --//xff:xff_archive, and XFF.md is regenerated.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second archive slice (#83): the dependency and the reader, still with no walk integration. Stacked on #436.
extra_modules/archive/is its own Bazel module@xff_archive, the same shape as the PCRE2 extra: it depends on@libarchive(from the BCR, no vendoring) and the shared@xff_extras_apiseams, never back into the xff core, so deleting the directory drops the extra entirely. Verified: the lean//xff/cli:xffhas zero libarchive in its dep graph, and the minimal-core build (deleteextra_modules/plus the extras' bazel_dep lines) still works.archive_readerlists an archive's members from memory or by streaming a file. libarchive detects the format and compression filter from content, so tar / zip / cpio / ar and the gz / bz2 / xz / zstd / lz4 filters all come through one entry point. It reads headers only, never member content, so listing a huge archive stays cheap.The error contract matters for the walk and is pinned by tests: "not an archive" (
InvalidArgument) must stay distinct from "corrupt archive" (DataLoss) - the first is an ordinary file, the second a real error to report. Empty input is explicitly not an archive: libarchive opens zero bytes and reports EOF, which would otherwise make an empty file look like a valid archive holding nothing.Licensing: libarchive is BSD-2-Clause and its codec closure (zlib, bzip2, liblzma, lz4, zstd on its BSD arm) is permissive throughout; mbedtls stays off, so no crypto arm is pulled. The notice self-registers from the reader's translation unit through the existing license-notice seam, so
--help=noticeand the NOTICE file stay complete by construction.Tests write real tar and gzip-filtered tar archives with libarchive's own write API and read them back - no committed binary fixtures - and cover the streaming file path plus the missing-file case.