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 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@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

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 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 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@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel