cabal-install-3.8.1.0: The command-line interface for Cabal and Hackage.
Copyright(c) David Himmelstrup 2005
Duncan Coutts 2011
LicenseBSD-like
Maintainercabal-devel@gmail.com
Stabilityprovisional
Portabilityportable
Safe HaskellNone
LanguageHaskell2010

Distribution.Client.FetchUtils

Description

Functions for fetching packages

Synopsis

fetching packages

fetchPackage :: Verbosity -> RepoContext -> UnresolvedPkgLoc -> IO ResolvedPkgLoc Source #

Fetch a package if we don't have it already.

isFetched :: UnresolvedPkgLoc -> IO Bool Source #

Returns True if the package has already been fetched or does not need fetching.

checkFetched :: UnresolvedPkgLoc -> IO (Maybe ResolvedPkgLoc) Source #

Checks if the package has already been fetched (or does not need fetching) and if so returns evidence in the form of a PackageLocation with a resolved local file location.

specifically for repo packages

fetchRepoTarball :: Verbosity -> RepoContext -> Repo -> PackageId -> IO FilePath Source #

Fetch a repo package if we don't have it already.

fetching packages asynchronously

asyncFetchPackages :: Verbosity -> RepoContext -> [UnresolvedPkgLoc] -> (AsyncFetchMap -> IO a) -> IO a Source #

Fork off an async action to download the given packages (by location).

The downloads are initiated in order, so you can arrange for packages that will likely be needed sooner to be earlier in the list.

The body action is passed a map from those packages (identified by their location) to a completion var for that package. So the body action should lookup the location and use waitAsyncFetchPackage to get the result.

Synchronous exceptions raised by the download actions are delivered via waitAsyncFetchPackage.

waitAsyncFetchPackage :: Verbosity -> AsyncFetchMap -> UnresolvedPkgLoc -> IO ResolvedPkgLoc Source #

Expect to find a download in progress in the given AsyncFetchMap and wait on it to finish.

If the download failed with an exception then this will be thrown.

Note: This function is supposed to be idempotent, as our install plans can now use the same tarball for many builds, e.g. different components and/or qualified goals, and these all go through the download phase so we end up using waitAsyncFetchPackage twice on the same package. C.f. #4461.

fetching other things

downloadIndex :: HttpTransport -> Verbosity -> RemoteRepo -> FilePath -> IO DownloadResult Source #

Downloads an index file to [config-dirpackagesserv-id] without hackage-security. You probably don't want to call this directly; use updateRepo instead.