tar-package was: Re: modules of cabal-install

[Christian Maeder]

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