Patch to read package-specific cabal-install config

[Carl Baatz]

Hi Erik,

thanks for the clarification -- being able to download from multiple 
repos is indeed useful. Understood about command line utility to upload. 
Having thought about this today, we think we might do something along 
the same line that integrates with version control. If we don't, I 
suspect we'll just use our patch and publish private packages using 
cabal upload.

Agree that it's a good idea to associate username and password with 
individual remote repos in the config. Still think it makes sense to 
have package specific cabal-install configs however -- as a way of 
giving a default for the cabal upload remote repo flag you suggest for 
example.

Thanks for your insight!

Best,

Carl

On 10/01/2012 11:30, Erik Hesselink wrote:
> Hi Carl,
>
> 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.
>
> Erik
>
> 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?
>>
>> Carl
>>
>>
>> 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:
>>> hackage.haskell.org:http://hackage.haskell.org/packages/archive
>>> 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 gmail.com>    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 haskell.org
>>>> http://www.haskell.org/mailman/listinfo/cabal-devel
>>>>
>>