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
IvanMiljenovic.wordpress.com
More information about the Libraries
mailing list