Patch to read package-specific cabal-install config
hesselink at gmail.com
Tue Jan 10 11:30:13 CET 2012
That's right, upload to multiple repo's doesn't work at all, for
multiple reasons. The advantage of multiple remote-repo's is that
cabal-install pulls from all repo's when installing a package. So you
can have packages depend on both private packages, and packages from
the public hackage, and install them with a simple 'cabal install'.
For upload, we've written a simple command line utility. I can share
part of the code, if you want. Or you can just use the web interface
to upload to your private hackage.
I think the 'right' solution for cabal upload and multiple remote
repo's is to have sections in the cabal file, and have fields like
username and password belong to a remote repo section. The upload
command then probably needs a flag to indicate to which remote repo
you want to upload.
On Tue, Jan 10, 2012 at 10:09, Carl Baatz <carl.baatz at gmail.com> wrote:
> 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:
>> 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,
>> On Mon, Jan 9, 2012 at 23:27, Carl Baatz<carl.baatz at gmail.com> wrote:
>>> Hi all,
>>> for packages that aren't for public consumption, we would like to specify
>>> private Hackage repo location. The simplest way we could think of to do
>>> 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
>>> file override the user config.
>>> The attached patch implements this, reading any file with a
>>> 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
>>> handling non-public packages?
>>> Many thanks,
>>> cabal-devel mailing list
>>> cabal-devel at haskell.org
More information about the cabal-devel