Cabal Bug / Feature and Improvement

[Duncan Coutts]

On Fri, 2008-12-26 at 22:03 +0000, Dominic Steinitz wrote:
> Duncan Coutts wrote:
> > On Wed, 2008-12-24 at 13:19 +0000, Dominic Steinitz wrote:
> >> Currently if I do not want to use the default locations for cabal then the 
> >> following:
> >>
> >>> dist\build\cabal\cabal.exe --config-file=urghh --remote-repo-cache=foo 
> >>                             --verbose=3 update
> >>
> >> will create urghh but will still (silently) put the repository cache at 
> >>
> >> repoLocalDir = "C:\\Documents and Settings\\steinitd\\Application 
> >> Data\\cabal\\packages\\hackage.haskell.org"
> > 
> > Ah so when the config file does not exist the --remote-repo-cache flag
> > is ignored and the default value from the newly created config file is
> > used instead.
> > 
> >> I've made a few changes which will put the cache at "foo".  I don't have access 
> >> to darcs at the moment so I've attached the changes. Let me know if a
> >> darcs patch is worth doing.
> > 
> > Yes please though check that it's not already fixed. I made some changes
> > in that code relatively recently.
> 
> Ok I've grabbed the latest version via darcs and you certainly have done
> something in this area. On linux I now get "foo" created with what look
> like the right things in it. However:
> 
> dom at lagrange:~/cabal-install> cat urghh
> remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive
> remote-repo-cache: /home/dom/.cabal/packages
> 
> which looks a bit suspicious to me as /home/dom/.cabal doesn't exist
> (presumably it isn't created). With my patch, "urghh" has what I believe
> is the correct remote-repo-cache of "foo".

So what you want is for the initial package config file to contain the
settings you specify on the command line? It seems to me that's likely
to lead to confusion because those settings would not be saved if the
config file already existed. If we want a way of creating a config file
from command line settings (and the use case for that is not at all
clear to me) then I think it should be explicit.

What seems more useful is to avoid creating any config file at all.

> I haven't had chance to see where you made your change but it doesn't
> look to be in the same area as where I made my change. If I get time
> tomorrow I'll have a look.

I think it's in Main. We combine (using mappend) flags from three
sources, the defaults, any config file and the command line.

> Do you concur with my view on what should be put in the config-file?

I'm not sure that I do. I think I'd like to see the bigger picture of
what you're really trying to achieve.

> > There are a couple other path settings that are still hard coded and
> > should really be configurable. We should also have a way to operate
> > without any config file at all for install scripts etc.
> > 
> 
> I think but I haven't checked that my change would over-write any
> hard-coded global flag. Is that the required behaviour? I think this
> could allow you to operate without a config file if all you need is the
> global flags. I suspect users will need other flags but I think a slight
> modification to the one I suggested could handle that by using "mappend"
> to override all the hard-coded settings. Something like this maybe:
> 
> > initialConf `mappend` (mempty {savedGlobalFlags = globalFlags}) 'mappend`
> > otherFlagsWhichNeedOverWriting

Honestly, I'm not quite sure what you're trying to do exactly. Perhaps
seeing the whole patch would help or if you can explain the use case.

Duncan