cabal for ghc 6.8.2, package upgrade warnings, please?

[Duncan Coutts]

On Mon, 2007-12-03 at 17:08 +0000, Claus Reinke wrote:
> > 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

I really don't like the idea of trying to parse ghc's error messages and
trying to divine some info out of them. I think the development time
needed to do that could be better spent making Cabal do dependency
analysis, in which case we could do our own error for when a package is
needed but it has not been declared as a dependency (or allow it to be
just a warning in some cases).

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

Yes, I think that's a good idea.

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

But it is legitimate to use a custom Setup.hs. I don't think we should
cast aspersions over them unnecessarily. Now if the cabal script
compiles the custom Setup.hs and it fails to compile then sure, we can
provide our best guesses and pointers to further information.

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

You can try both now. They're available from hackage and the development
versions are on darcs.haskell.org.

> Setup.hs should neither be mentioned ("cabal configure"
> instead of "runhaskell Setup.hs configure")

Right, cabal-install and cabal-setup do not mention Setup.hs in their
help messages.

> nor exist in the package directory (a library of useful defaults,
> selected by .cabal build-types, should be part of the cabal
> installation).

The Setup.hs is only required if you use build-type: Custom.

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

That is indeed current policy. So we should consider promoting the use
of build-type by warning whenever it is missing.

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

I'm included to agree. Perhaps if build-type is Custom then we should
require both a lower and upper bound in the cabal-version field. We can
assume that Cabal itself is following the package version policy.

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

That does seem pretty hard.

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

Yes.

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

We have the trac. We can use the priority and field that indicates the
amount of time we think the task will take.

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

Thanks.


Duncan