Duncan Coutts wrote: [...]
data Entry fileName :: Entry -> FilePath fileContent :: Entry -> ByteString [...] Maybe only a "isNormalFile" test-function for an Entry is missing.
isNormalFile entry = fileType entry == NormalFile
No we really want one of these for every file type? isDirectory, isHardLink. I hope not. So perhaps that means you just want to expose fileType and FileType too in the top level API.
I only suggested isNormalFile in order to test, if fileContent can be reasonably used. Directly working with FileType and Entry should be for experts only. Surely the file types Directory and SymbolicLink/HardLink (a single "isLink" test) may be of some user interest, too, but for these types fileContent has no meaning and additionally the linkTarget should be exported. For directories the entry does not reveal the contents. Therefore, I think, fileName, fileContent, and isNormalFile is just enough for a top level API.
checkSecurity is not needed in the API, because it is done by unpack. (checkTarBomb does nothing currently).
It's needed if you're checking a tar file now because you expect to unpack it later, eg on hackage.
It's perfect in Codec.Archive.Tar.Check
Tar entries should (usually will) not be constructed by the user.
I've got a use case where we do.
Ok, importing Codec.Archive.Tar.Types and Codec.Archive.Tar.Pack should be fine then.
getDirectoryContentsRecursive does not really belong into this tar package.
True but it's so useful you'd have to implement it yourself if it was not provided. We can't get it into the System.Directory package very quickly.
Keeping it for a while in Codec.Archive.Tar.Pack only, should be fine. (A separate module is overkill.) [...]
So rather than re-exporting almost everything from the other modules in the top module, I suggest my API above and simply expose all other modules in case some wants the internals.
Ok, so perhaps we should split the API into two, in the way you suggest above. I'll try that and see how it looks. [...]
Thanks again, Christian