cabal for ghc 6.8.2, package upgrade warnings, please?

[Claus Reinke]

> I'm not sure we actually can guess if a package is broken by the base
> split or not.
>
> build-depends: base
>
> so does it really only depend on base or does it depend on base, pretty,
> directory etc etc. No idea.

not directly. but you could then filter the error messages
and provide helpful higher-level hints. example filter rules:

- build-depends: base
   error message:
         "member of package _, which is hidden"
        (where _ is any of the packages split from base)
   emit hint:
        the base package has been split up, please check
        <url>
        for package upgrade information

- error message:
        Couldn't match expected type
        `(Either GenericPackageDescription  PackageDescription,
        HookedBuildInfo)'
    emit hint:
        Setup.[l]hs uses part of the internal cabal api that
        has changed. see <url> for upgrade tips or ask on
        cabal-devel at .

- there is no build-type field
  emit warning:
        please update package description. see <url>

- there is a non-standard Setup.[l]hs
   emit warning:
        non-standard Setup.[l]hs, uses internal cabal api.
        this api is subject to development, and need not be
        used for most packages. see
        <url>
        (the url should invite package authors to report gaps
        that force them to write their own Setup.[l]hs to
        cabal-devel@)

such things could work by simple pattern matching over
the compiler error messages, in the cabal commandline
interface. a lot cheaper than the other alternatives, can
be improved incrementally, and provides users with
high-level hints and further information on what to do.

anything to prevent them from running away blogging
noisily about how haskell packages do not even install.

> We do have this now and we'll be promoting it more in future. We
> currently have the cabal-setup program and the cabal-install program.
> We're currently working on merging the two into a more general cabal
> front end / cli UI program.

similar to darcs, ghc-pkg, etc? that would be great.

Setup.hs should neither be mentioned ("cabal configure"
instead of "runhaskell Setup.hs configure") nor exist in the
package directory (a library of useful defaults, selected by
.cabal build-types, should be part of the cabal installation).

explicit use of Setup.hs should be reserved for exceptions,
where cabal does not (yet) cover the functionality needed.

> cabal-version: >=1.2 ..
> and the like. This is the same problem as we have with package
> dependencies. The package version policy is one approach to
> solving this.

if that is likely to cause problems, how about a warning,
with link to policy url?-)

and how do you determine the cabal api version a Setup.hs
was written against? if the Setup.hs is non-standard, any use
of ranges in cabal-version: (let alone absence of that field)
should be an error.

> We currently cannot check if a package depends on containers without
> declaring it because Cabal does not do any of it's own module chasing.
> When it does we'll be able to do a bit better here.

okay, but you could help the package user to interpret the
compiler error messages, as outlined above.

> This is all stuff we should have of course. My immediate reaction I
> admit is that it sounds like a lot of work that might be better invested
> in just improving the design of cabal generally.

that would be true if cabal wasn't already out in the field!-)

> What you're proposing generally really is a lot of work and I think
> requires rather more active Cabal hackers, or a much slower rate of
> change.

hm, darcs has the same problem. how about using the upcoming
communities report to ask for some essential community tool
hacking?-)

the cabal and darcs developers could set up a page with
well-defined tasks in priority order, and invite all those
shootout/euler/xmonad hackers to spend January, say, on
tackling as many of those tasks as possible while discussing
the issues arising on the usual mailing lists and collecting karma;-)

it should be restricted to darcs+cabal, to avoid losing hacking
power to other distracting projects, it should be limited in time,
to get people to focus their efforts, and the core developers
would have to prepare the ground, select the tasks, and
provide assistance. you could coordinate with the darcs
developers, and haskell-cafe people do tend to flock toward
projects where they can be seen and can chat with others
working on the same issues:-)

just another thought,
claus