The high-level API in Codec.Archive only exposes a very limited amount of functionality compared to what libarchive itself actually offers. When using the library I've found there's a vacuum between the very nice high-level API and having to re-implement a lot of what already exists internally atop the foreign code in order to access more of the libarchive functionality, such as write filters.
For example, because Codec.Archive.Pack and similar code is hidden - you're limited to the formats that the functions exported from Codec.Archive expose, like packToFile<Format>, etc. If you want to add filters and say, create a .tar.xz or .tar.gz compressed archive - you need to re-implement a non-trivial amount of what already exists in Codec.Archive.Pack just so you can insert the call to archive_write_add_filter_xz. It feels like Codec.Archive.Pack.{filePacker,entriesToFileGeneral} (and similarly for .Unpack) are too useful to remain hidden unless the high-level API comprehensively supports all permutations of filters/formats for writing/reading. I'd rather not have to re-implement the wheel and the overhead of forking, PRing, and so on just to add a new top-level function/export for a certain bespoke combination of filters/formats feels like overkill.
Similarly when reading an archive the filters/formats are set to all - which doesn't give the user an option of configuring only a (potentially safe) subset of those supported.
There's also a related but much smaller issue with creating Entry values from raw FilePaths if you're constructing an archive from a collection of files - having to replicate Codec.Archive.Pack.Common verbatim.
Perhaps if there was an API that lets you have at the ArchivePtr similarly to how Codec.Archive.Pack.entriesToFileGeneral works, as this would allow you to set filters/formats as required without being restricted to what Codec.Archive exports - a sort of midway between Codec.Archive and Codec.Archive.Foreign.* in terms of power to weight. An alternative would be to make more modules available as .Internal.* so we can make use of the existing plumbing a bit more.
The high-level API in
Codec.Archiveonly exposes a very limited amount of functionality compared to whatlibarchiveitself actually offers. When using the library I've found there's a vacuum between the very nice high-level API and having to re-implement a lot of what already exists internally atop the foreign code in order to access more of thelibarchivefunctionality, such as write filters.For example, because
Codec.Archive.Packand similar code is hidden - you're limited to the formats that the functions exported fromCodec.Archiveexpose, likepackToFile<Format>, etc. If you want to add filters and say, create a.tar.xzor.tar.gzcompressed archive - you need to re-implement a non-trivial amount of what already exists inCodec.Archive.Packjust so you can insert the call toarchive_write_add_filter_xz. It feels likeCodec.Archive.Pack.{filePacker,entriesToFileGeneral}(and similarly for.Unpack) are too useful to remain hidden unless the high-level API comprehensively supports all permutations of filters/formats for writing/reading. I'd rather not have to re-implement the wheel and the overhead of forking, PRing, and so on just to add a new top-level function/export for a certain bespoke combination of filters/formats feels like overkill.Similarly when reading an archive the filters/formats are set to
all- which doesn't give the user an option of configuring only a (potentially safe) subset of those supported.There's also a related but much smaller issue with creating
Entryvalues from rawFilePaths if you're constructing an archive from a collection of files - having to replicateCodec.Archive.Pack.Commonverbatim.Perhaps if there was an API that lets you have at the
ArchivePtrsimilarly to howCodec.Archive.Pack.entriesToFileGeneralworks, as this would allow you to set filters/formats as required without being restricted to whatCodec.Archiveexports - a sort of midway betweenCodec.ArchiveandCodec.Archive.Foreign.*in terms of power to weight. An alternative would be to make more modules available as.Internal.*so we can make use of the existing plumbing a bit more.