Hackage rejecting packages
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. -Iavor
On Fri, 28 Oct 2011, Iavor Diatchki wrote:
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.
I do not expect that functions simply disappear, but I expect that 'base' will be further split into smaller packages.
Iavor Diatchki writes:
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.)
It's not new: hackage rejects anything that Cabal's checkPackage marks
as worse than suspicious, and this became such an error some time ago:
Mon Jun 1 20:16:29 BST 2009 Duncan Coutts
On 29 October 2011 07:41, Iavor Diatchki
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@gmail.com IvanMiljenovic.wordpress.com
participants (4)
-
Henning Thielemann -
Iavor Diatchki -
Ivan Lazar Miljenovic -
Paterson, Ross