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.