Provide API for getting a package hash

[edsko]

No description provided.

[edsko]

I've significantly refactored the whole API for accessing the Hackage index, because it was getting a bit messy. The new API is now also used internally (for instance, by downloadPackage, which is now very simple). The first change is that IndexFile (a structured type describing files in the index) has gotten a type argument, indicating the type of the corresponding decoded file. Right now this is () for all files except the metadata, because those are the only ones we parse; it would be easy to fix this but it's not a priority; opened a separate ticket about that (#140).

There are now two APIs. The first is for accessing the directory:

data Directory = Directory {
    directoryFirst   :: DirectoryEntry
  , directoryNext    :: DirectoryEntry
  , directoryLookup  :: forall dec. IndexFile dec -> Maybe DirectoryEntry
  , directoryEntries :: [(DirectoryEntry, IndexPath, Maybe (Some IndexFile))]
  }

The second is for reading files form the index proper. The function is:

withIndex :: Repository down -> (IndexCallbacks -> IO a) -> IO a

where IndexCallbacks provides all kinds of functions that access the index:

data IndexCallbacks = IndexCallbacks {
    indexLookupEntry     :: DirectoryEntry -> IO (Some IndexEntry, Maybe DirectoryEntry)
  , indexLookupFile      :: forall dec. IndexFile dec -> IO (Maybe (IndexEntry dec))
  , indexLookupFileEntry :: forall dec. DirectoryEntry -> IndexFile dec -> IO (IndexEntry dec)
  , indexLookupCabal     :: PackageIdentifier -> IO (Trusted BS.L.ByteString)
  , indexLookupMetadata  :: PackageIdentifier -> IO (Trusted Targets)
  , indexLookupFileInfo  :: PackageIdentifier -> IO (Trusted FileInfo)
  , indexLookupHash      :: PackageIdentifier -> IO (Trusted Hash)
  , indexDirectory       :: Directory
  }

@dcoutts note in particular that this provides indexLookupHash; it's worth keeping in mind however that this operation is not entirely trivial; it needs to lookup the targets.json file in the index (first looking up its offset in the directory), then parse it, and finally read the SHA256 from the parsed format. If this is too slow we should probably add these hashes to the cache (related to @hvr 's extended cache, perhaps).

I think this new API is a lot cleaner, and can now easily be extended if necessary.