{"push_id":926057005,"size":1,"distinct_size":1,"ref":"refs/heads/pr/RepoContext","head":"05c7739c0c70871032e096af247f20fdf2f8ff82","before":"5eead0801825f59cdd6b724d7c2eea0e3dcb7af9","commits":[{"sha":"05c7739c0c70871032e096af247f20fdf2f8ff82","author":{"email":"952159fa9895ee1dd90d06c086a9b6e7b9efd6e3@well-typed.com","name":"Edsko de Vries"},"message":"Introduce RepoContext\n\nThe RepoContext encapsulates the list of repositories, as well as some\nassociated state. In particular, it also encapsulates the HttpTransport, which\nwill be initialized on demand and cached thereafter.  This is important for two\nreasons:\n\n* For the hackage-security integration: in order to be able to use cabal's own\n  HttpTransport API for the secure repo, we need to have access to that\n  transport when we initialize the repo, but as things stood that was not\n  possible (cabal was initializing repos ahead of time but the transport on\n  demand).\n\n* For the integration with the nix-local-branch it is important that the Repo\n  type remains Serializable. By passing RepoContext rather than a list of\n  Repos, we can leave RepoSecure serializable and separately maintain a mapping\n  from cabal's Repo type to hackage-security's (stateful) Repository type.","distinct":true,"url":"https://api.github.com/repos/edsko/cabal/commits/05c7739c0c70871032e096af247f20fdf2f8ff82"}]}