Hackage rejecting packages

Ivan Lazar Miljenovic ivan.miljenovic at gmail.com
Sat Oct 29 01:38:34 CEST 2011

On 29 October 2011 07:41, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> Hello,
> I just noticed that the public Hackage server has started refusing to
> accept packages that do not have an upper bound on "base".     I think
> that this crosses the line of useful static checking and, instead of
> helping package maintainers, it creates more work for them.  (A
> warning to the same effect would be just fine.)
> Why do I think that?  Choosing a conservative upper bound for the
> 'base' dependency of a library does not really lead to more stable
> builds---while it ensures that your library will build correctly, it
> tends to cause failures in the building of applications that use your
> library (because there is no set of packages that satisfies the
> combined dependencies).   This is particularly true for the case of
> "base" because all packages depend on it.  So placing a conservative
> constraint automatically makes your library incompatible with any
> package that might use a feature that was introduced after the
> constraint.
> While, in principle, "base" could completely change in the future, in
> practice there is a fairly large set of functions that are quite
> stable and it is not hard to write fairly future proof code. I think
> that it should be up to the maintainer to decide if they have an upper
> bound or not, just like with any other package.

Then again, there have been some packages (including relatively
popular ones) that had constraints like "base < 5" back in the days of
GHC 6.8, and when 6.10 came out with base-4, they completely broke
(due to exception handling I think).  So unless your package is _very_
conservative with which parts of base it uses, then I think it's
preferable to have such upper bounds.

Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com

More information about the Libraries mailing list