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