Cabal Bug / Feature and Improvement

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Cabal Bug / Feature and Improvement

Dominic Steinitz
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"

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.

Dominic.

In Config.hs:

loadConfig :: Verbosity -> GlobalFlags {-Flag FilePath-} -> Flag Bool -> IO
SavedConfig
loadConfig verbosity globalFlags {-configFileFlag-} userInstallFlag =
addBaseConf $ do
  configFile <- maybe defaultConfigFile return (flagToMaybe (globalConfigFile
globalFlags){-configFileFlag-})

  minp <- readConfigFile mempty configFile
  case minp of
    Nothing -> do
      notice verbosity $ "Config file " ++ configFile ++ " not found."
      notice verbosity $ "Writing default configuration to " ++ configFile
      commentConf <- commentSavedConfig
      initialConf <- initialSavedConfig
      writeConfigFile configFile commentConf (initialConf `mappend` (mempty
{savedGlobalFlags = globalFlags}))
      return initialConf

The other cases of loadConfig are unchanged.

In Main.hs global replace:

loadConfig verbosity (globalConfigFile globalFlags)

by

loadConfig verbosity globalFlags



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Cabal Bug / Feature and Improvement

Duncan Coutts
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.

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.

Duncan

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Cabal Bug / Feature and Improvement

Dominic Steinitz
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@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".

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.

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

>
> 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

Dominic.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 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@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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Cabal Bug / Feature and Improvement

Dominic Steinitz
Duncan Coutts <duncan.coutts <at> worc.ox.ac.uk> writes:

> 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.
>

>
> 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.

Here's my use case. I've expressed in the form of requirements and how I think
they could be solved using ghc and cabal.

We have a small team of developers and a much larger team of users who use a
very restricted subset of Haskell.

We have a version control system. We want everyone to use exactly the same
community packages. Currently, we keep these packages under version control and
manually modify ghc's package.conf (also under version control).  The reason we
do this is that the developers and users are able to check out sources to an
arbitrary location on their local disk and we want the users to be able to
build and run our code without manual configuration or separate installation of
anything. Furthermore, each developer and user could have several "workspaces"
(checked out versions of the sources at different locations on their local
disk) on the go at the same time. We modify ghc's package.conf to use $topdir
and relative paths - see http://www.nabble.com/Re%3A-haddock-not-finding-base-
lib-docs----%24topdir---p7699303.html - so that package.conf is in sync with
the place where the developer / user has checked out their sources (without
package.conf needing to be modified on a per user and per workspace basis).

The requirement for everyone to use the exactly the same community packages is
partly driven by audit requirements. Furthermore, because we are behind a
proxy, currently we would have to get every user to modify their registry if we
wanted them to install community packages. We'd rather not do that especially
as these settings can get over-written e.g. when Internet Explorer gets patched.

We'd like to move away from manually modifying ghc's package.conf and to doing
things the community way by using cabal more. Here's what I think would work.

1. A developer realises that package A is required. He cabal fetches to a
remote-repo-cache which is under version control. This will also fetch any
dependencies.

2. He installs package A using the remote-repo-cache and specifying --package-
db. Note that the package-db is "[]" in the version control system and only
every gets updated in the checked out source. It never gets checked back in.
The cabal install of package A updates the package-db.

3. He uses e.g. ghci with -package-conf, -no-user-package-conf and -package A.

4. He checks in the remote-repo-cache.

4. Now another developer wishes to work on the code.

5. He checks out the sources from version control and cabal installs all the
packages in the remote-repo-cache specifying --package-db. We'd probably do
this in our build system by automatically building any package that has
appeared in the repo-cache since the last update. He now has all the packages
in the remote-repo-cache and his package.db has been updated to reflect this
even though the file itself is not ever checked into the version control
system. We'd certainly want this to happen behind the scenes for our users who
will not add packages but who will certainly use them (even if they don't
realise they are).

Dominic.


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries