Patch to read package-specific cabal-install config

Carl Baatz carl.baatz at
Tue Jan 10 10:09:13 CET 2012

Hi Erik,

thanks for the suggestion! I tried that, though it appears that the 
cabal-install upload command picks up the last repo specified when 
running the upload command (Distribution.Client.Upload:65), without an 
option to instead use one of the other repos. It's not clear to me what 
the advantage of specifying > 1 remote-repo in the config file is.

The idea we had was to enable 'cabal upload' both for public packages 
going to public Hackage and for private packages going to a private Hackage.

Does that make sense or am I missing something?


On 10/01/2012 09:33, Erik Hesselink wrote:
> Hi Carl,
> At Silk, we use a private hackage. You can just enter it in your main
> cabal config (~/.cabal/config) as an extra entry:
> remote-repo:
> remote-repo:<our-hackage-name>:<our-hackage-url>
> The only thing that doesn't work well, is the username/password for
> 'cabal upload': these are not per remote repo, but they should be.
> Hope this helps,
> Erik
> On Mon, Jan 9, 2012 at 23:27, Carl Baatz<carl.baatz at>  wrote:
>> Hi all,
>> for packages that aren't for public consumption, we would like to specify a
>> private Hackage repo location. The simplest way we could think of to do this
>> was to read a config file in the same format as the user config
>> (~/.cabal/config) from the current directory and let any flags set in that
>> file override the user config.
>> The attached patch implements this, reading any file with a .cabal-install
>> extension (including '.cabal-install'). It errors out if more than one
>> .cabal-install file is found or if there's a parse error on the
>> .cabal-install file.
>> Does this sound like a good idea? If not, any ideas for alternative ways of
>> handling non-public packages?
>> Many thanks,
>> Carl
>> _______________________________________________
>> cabal-devel mailing list
>> cabal-devel at

More information about the cabal-devel mailing list