On the Haskell Platform
Dear list, I have written a package, reactive-banana-wx, which seems to be quite enticing to Haskell beginners. It's an implementation of the fabled functional reactive programming (FRP), so it's natural that people want to play around with it to see what it is all about. I imagine that the latest parallelism packages also serve a similar audience. Of course, to play around with a package, you have to be able to install it, hopefully painlessly. As the maintainer, I have adopted the following principles as they appeared sound to me: 1. My package installs and works without any hitch on the latest Haskell Platform. This is easier said than done, because one of my dependencies is wxHaskell, which tends to have hitches at times. Occasionally, I restrict the version number to a specific, older wxHaskell version that I know to be bug free. In other words, the idea is that a complete Haskell beginner will be able to install my package with the standard setup even if he knows nothing about the Haskell ecosystem. 2. If the user has a setup that doesn't fit the dependencies I prescribe, then I expect him to change the version constraints himself (and hopefully tell me whether it works.) The idea is that having a non-standard setup is an indication that the user is no longer a beginner, so I can expect him/her to know how to change version constraints. With these principles in mind, imagine my surprise, then, to discover that the "Haskell Platform" on Ubuntu 12.04 includes GHC 7.4.1 http://packages.ubuntu.com/precise/haskell-platform Clearly, this must be a fake Haskell Platform, because the latest real Haskell Platform is still at GHC 7.0.4 at the time of this writing. Unfortunately, my principle 1 is now rendered moot. I don't quite know what to do. I understand that there is a need to get the latest GHC into the standard setup, but creating a "fake" Haskell Platform seems like a mistake to me, as it contradicts the use case "complete Haskell beginner" I described above. Not to mention that I'm stuck with the "real" Haskell Platform on Mac OS X and would have to manage separate cabal installations if I want to thoroughly test my package for all compiler versions. Or is it my principles that need to change? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com
Heinrich Apfelmus
With these principles in mind, imagine my surprise, then, to discover that the "Haskell Platform" on Ubuntu 12.04 includes GHC 7.4.1 http://packages.ubuntu.com/precise/haskell-platform Clearly, this must be a fake Haskell Platform, because the latest real Haskell Platform is still at GHC 7.0.4 at the time of this writing. Unfortunately, my principle 1 is now rendered moot.
That Ubuntu package is just a direct port from Debian. So I am adding a CC to Joachim, our resident Debian packaging hero, hoping for comment on the issue. Thanks, Yitz
[Re-Sending, the mailing list is picky about sender e-mail addresses.] Hi Heinrich, Am Freitag, den 11.05.2012, 10:23 +0200 schrieb Heinrich Apfelmus:
With these principles in mind, imagine my surprise, then, to discover that the "Haskell Platform" on Ubuntu 12.04 includes GHC 7.4.1
http://packages.ubuntu.com/precise/haskell-platform
Clearly, this must be a fake Haskell Platform, because the latest real Haskell Platform is still at GHC 7.0.4 at the time of this writing. Unfortunately, my principle 1 is now rendered moot.
the problem with packaging the platform is that distributions have a one-version-per-package policy, so we can not always have exactly the version present in the latest platform, e.g. because other packages require a newer version, or just because the old version is too old and buggy and our users want newer versions. Therefore, we take the liberty to diverge a bit. You can see the current status for Debian on http://people.debian.org/~nomeata/platform.html Furthermore, in the development brach of Debian, unstable, we prepare the next releases and currently package the versions that we expect for the platform 2012.2.0.0. You can see that the version you linked to is such an prerelease by the version number (2012.1.0.0~debian1). In Debian, we would avoid having such a prerelease in a stable release (but might decide that it could still be better than having too old versions of compiler and libraries). I can’t speak for Ubuntu in that regard.
I don't quite know what to do. I understand that there is a need to get the latest GHC into the standard setup, but creating a "fake" Haskell Platform seems like a mistake to me, as it contradicts the use case "complete Haskell beginner" I described above. Not to mention that I'm stuck with the "real" Haskell Platform on Mac OS X and would have to manage separate cabal installations if I want to thoroughly test my package for all compiler versions. Or is it my principles that need to change?
From a distro point of view I can only say: We made policies and decisions that lead to us not being able to provide up-to-date libraries _and_ the latest (or even all) platform versions, so this problem will likely stay around for a while. What we can offer, though, is to package your software. A „complete Haskell beginner“ should maybe use distro-packaged libraries in the first place, precisely because the distribution takes care of these issues for him. Greetings, Joachim -- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/
Joachim Breitner wrote:
Heinrich Apfelmus wrote:
Clearly, this must be a fake Haskell Platform, because the latest real Haskell Platform is still at GHC 7.0.4 at the time of this writing. Unfortunately, my principle 1 is now rendered moot.
The problem with packaging the platform is that distributions have a one-version-per-package policy, so we can not always have exactly the version present in the latest platform, e.g. because other packages require a newer version, or just because the old version is too old and buggy and our users want newer versions. Therefore, we take the liberty to diverge a bit. You can see the current status for Debian on http://people.debian.org/~nomeata/platform.html
[..] From a distro point of view I can only say: We made policies and decisions that lead to us not being able to provide up-to-date libraries _and_ the latest (or even all) platform versions, so this problem will likely stay around for a while.
I see. Thinking about this, it appears to me that the only way to meet the "one-version-per-package" constraint is the following approach on my part: A. Always support the latest version of a dependency (compiler, library, ...), i.e. the upper bounds of my version constraints have to match the latest stuff. B. If desired, support older versions of a dependency by adjusting the lower bounds of my version constraints. This way, my package can never be blamed when it fails to install; rather, "the blame" falls on the user for not upgrading his system. (Package management is probably best seen as a "blame game". Scenario: "This package fails to install, who is to blame?" Usually, the user can only assign responsibility to the author of the package, even though the latter may not have direct control over the problem. Of course, the overall goal of package management is to route responsibility to the right person who can fix it.) However, this approach is not without problems. The first problem is this: what happens if the newer version of my dependency has a bug? This happened to me in the case of GHC 7.2 and now also in the case of wx-0.90 . Unfortunately, neither waiting for an upstream fix (GHC-7.2) nor working on an upstream fix myself (wx-0.90) will help: I have to implement a workaround in my own package if I want to keep it usable for everyone who has already installed the buggy dependency. I tried to depend on an older version, but doesn't fly with the approach above. The second problem is that the lower bounds will tend to be higher than necessary. The thing is that once I install the new dependency on my machine and develop a new feature in my package, I can no longer test whether my package still works with the old version. That would require me have both versions of my dependency installed at the same time, which is very tricky with the "one-version-per-package" assumption. Unable to test the old version, I cannot, in good conscience, include a dependency on the old version. (However, doing so is not too bad for me, because I can deflect "the blame" in case it doesn't work.)
What we can offer, though, is to package your software. A „complete Haskell beginner“ should maybe use distro-packaged libraries in the first place, precisely because the distribution takes care of these issues for him.
That's a good idea. Unfortunately, it doesn't help with the issue at hand (new dependency has a bug, old dependency requires old Haskell Platform). Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com
Hi, Am Sonntag, den 13.05.2012, 21:36 +0200 schrieb Heinrich Apfelmus:
From a distro point of view I can only say: We made policies and decisions that lead to us not being able to provide up-to-date libraries _and_ the latest (or even all) platform versions, so this problem will likely stay around for a while.
I see. Thinking about this, it appears to me that the only way to meet the "one-version-per-package" constraint is the following approach on my part:
A. Always support the latest version of a dependency (compiler, library, ...), i.e. the upper bounds of my version constraints have to match the latest stuff.
B. If desired, support older versions of a dependency by adjusting the lower bounds of my version constraints.
yes, always supporting the latest version available on hackage is a good idea. If everyone would be doing that I would not have to send „please upgrade your package to mtl-2.1 / transformers-0.3“ mails now. Having the lower version include other common versions (i.e. the latest platform release and/or versions found in distribution releases you care about) is a good idea as well.
This way, my package can never be blamed when it fails to install; rather, "the blame" falls on the user for not upgrading his system.
(Package management is probably best seen as a "blame game". Scenario: "This package fails to install, who is to blame?" Usually, the user can only assign responsibility to the author of the package, even though the latter may not have direct control over the problem. Of course, the overall goal of package management is to route responsibility to the right person who can fix it.)
Well, for a distro package user, he is expected to first blame the distro (unless he is knowledgable enough to know that a certain bug/problem is caused by upstream). Not all users know that, though, and it does not help if there is a conflict between a distribution-provided package and code taken from somewhere else.
However, this approach is not without problems.
The first problem is this: what happens if the newer version of my dependency has a bug? This happened to me in the case of GHC 7.2 and now also in the case of wx-0.90 . Unfortunately, neither waiting for an upstream fix (GHC-7.2) nor working on an upstream fix myself (wx-0.90) will help: I have to implement a workaround in my own package if I want to keep it usable for everyone who has already installed the buggy dependency. I tried to depend on an older version, but doesn't fly with the approach above.
I would suggest to exclude the broken versions from your dependency. cabal-install users will then hopefully get your package built against an older, non-buggy version.
The second problem is that the lower bounds will tend to be higher than necessary. The thing is that once I install the new dependency on my machine and develop a new feature in my package, I can no longer test whether my package still works with the old version. That would require me have both versions of my dependency installed at the same time, which is very tricky with the "one-version-per-package" assumption. Unable to test the old version, I cannot, in good conscience, include a dependency on the old version. (However, doing so is not too bad for me, because I can deflect "the blame" in case it doesn't work.)
This is a general problem in the Haskell ecosystem that not all build-dependencies combinations can be tested. For a few targets, you can test it using different ~/.cabal directories or probably some of the recent cabal-enhancing tools (cabal-dev et. al.), which I don’t know myself. Or just do the RERO-principle and assume things work until someone complains. But you are right in that things are not so easy to get perfectly right :-) Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata@joachim-breitner.de
On Sun, 13 May 2012, Joachim Breitner wrote:
yes, always supporting the latest version available on hackage is a good idea. If everyone would be doing that I would not have to send „please upgrade your package to mtl-2.1 / transformers-0.3“ mails now.
Defending myself: I had already updated my packages to transformers-0.3 in the repositories, but I have not released all of them to Hackage immediately. Updating a dependency in 30 packages needs some time although I did even not need to alter any code.
On Sun, May 13, 2012 at 09:36:40PM +0200, Heinrich Apfelmus wrote:
Joachim Breitner wrote:
Heinrich Apfelmus wrote: [...] I see. Thinking about this, it appears to me that the only way to meet the "one-version-per-package" constraint is the following approach on my part:
A. Always support the latest version of a dependency (compiler, library, ...), i.e. the upper bounds of my version constraints have to match the latest stuff.
B. If desired, support older versions of a dependency by adjusting the lower bounds of my version constraints.
This is exactly what I try to do with the few packages I've written and put on Hackage.
However, this approach is not without problems.
The first problem is this: what happens if the newer version of my [...] version, but doesn't fly with the approach above.
The second problem is that the lower bounds will tend to be higher than necessary. The thing is that once I install the new dependency on my machine and develop a new feature in my package, I can no longer test whether my package still works with the old version. That would require me have both versions of my dependency installed at the same time, which is very tricky with the "one-version-per-package" assumption. Unable to test the old version, I cannot, in good conscience, include a dependency on the old version. (However, doing so is not too bad for me, because I can deflect "the blame" in case it doesn't work.)
Luckily I've never had to deal with the first issue. The second on the other hand I have a rather lazy process for: *I* release packages with the dependencies that I've tested, then I'm happy to accept patches that relax the dependencies downwards (and sometimes upwards, when I'm slow) from users, as long as they claim to have run the test suites. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay
participants (5)
-
Heinrich Apfelmus -
Henning Thielemann -
Joachim Breitner -
Magnus Therning -
Yitzchak Gale