RE: cabal release (was: cabal experiences)
| then. 1.2 might be a good version to get into ghc 6.6, though I | expect that it won't have configurations or shipments, since we won't | have much time to try those out. What's the schedule like for ghc 6.6? Well, the plan is for 6.6 to have impredicative types, and revised GADTs. I'd like to fix the interaction of type classes and GADTs too. And we'd like to have shaken down the parallel implementation a bit. The natural time for 6.6 feels like at least 3 months from now -- and we'd rather not get pinned down to any dates for a while yet. If the reason you want 6.6 is to get a new Cabal, why not download a new Cabal package? Or is there another reason you want 6.6? Bug-fixes to 6.4 are a much smaller deal. Simon
On Mon, 2005-12-12 at 14:46 +0000, Simon Peyton-Jones wrote:
If the reason you want 6.6 is to get a new Cabal, why not download a new Cabal package? Or is there another reason you want 6.6?
That is exactly the problem. All non-trivial packages need a later version of Cabal since there are many many minor bug fixes and little feature additions in later versions of Cabal. So it's fine for package developers to download a later Cabal version but the sense some people have is that they can't ask their users to upgrade their Cabal installation from the one that comes with GHC.
Bug-fixes to 6.4 are a much smaller deal.
The improvements are a mixture of bug fixes and feature additions and some api changes. So because of the policy for minor versions of GHC is to not change any apis including those of Cabal, GHC 6.4.1 came with a version of Cabal that is widely acknowledged to be buggy and unsuitable for many packages and distributors. We can sometimes persuade users to upgrade their Cabal package separately from their GHC installation, but not always. In Gentoo we made a decision to ship Cabal-1.1.3 with GHC 6.4.1. That is after installing GHC 6.4.1 we unregister Cabal-1.0 and install Cabal-1.1.3. We do not allow any choice in that. This was necessary because our build/distribution infrastructure could not work around the bugs in Cabal-1.0 and besides many packages that we want to distribute require later versions of Cabal. So Gentoo users are ok, but other users are not. So this is why there is pressure in some quarters for a major release, (6.6) rather than another minor release (6.4.2) since the former would allow package authors to support a released version of GHC because it would come with a usable version of Cabal. A minor release with the same Cabal-1.0 would leave people in the same situation as now. I appreciate that we do not want to rush the next major release because there are new features that need to be got right. Perhaps we should think again about which Cabal version to include in the next GHC minor version, or perhaps to advise users in the release notes for GHC 6.4.2 that it is highly recommended to upgrade to Cabal version x.y. Perhaps another compromise would be for GHC 6.4.2 to ship more than one version of Cabal. It could ship version 1.0 and have that exposed by default so that GHC's api stability guarantees could be met and it could also ship a more recent version that we can agree upon so that it would be much less difficult for the average user to build packages that require more recent Cabal versions. Duncan
On Mon, Dec 12, 2005 at 03:14:09PM +0000, Duncan Coutts wrote:
In Gentoo we made a decision to ship Cabal-1.1.3 with GHC 6.4.1. That is after installing GHC 6.4.1 we unregister Cabal-1.0 and install Cabal-1.1.3.
If all distributions and users are going to have to do this to get a usable system[1] then it seems obvious to me that ghc should already come this way. That it doesn't causes headaches for packagers IME. [1] "usable system" is a bit strong, but I hope you understand what I mean.
I appreciate that we do not want to rush the next major release because there are new features that need to be got right. Perhaps we should think again about which Cabal version to include in the next GHC minor version, or perhaps to advise users in the release notes for GHC 6.4.2 that it is highly recommended to upgrade to Cabal version x.y.
Incidentally, I would be happy if 6.4.2 was renamed 6.6 and newer cabal added; I'm not asking for what is currently called 6.6 necessarily. Or adding newer cabal to 6.4.2, against the policy, would suit me fine too. Thanks Ian
On Mon, Dec 12, 2005 at 03:14:09PM +0000, Duncan Coutts wrote:
On Mon, 2005-12-12 at 14:46 +0000, Simon Peyton-Jones wrote:
If the reason you want 6.6 is to get a new Cabal, why not download a new Cabal package? Or is there another reason you want 6.6?
That is exactly the problem. All non-trivial packages need a later version of Cabal since there are many many minor bug fixes and little feature additions in later versions of Cabal.
This is a large part of the reason I'd like to see cabal as a completly separate package from any compiler with a programatic interface rather than a library one. things will get very complicated when there are multiple major compilers and you have to tell users things like 'run runhaskell Setup.lhs, unless your runhaskell points to jhc, in which case do runghc Setup.lhs, oh, create a link from runhaskell to your proper compiler'. We can do so without losing any flexability at all. just add a new line to the cabal file build-style: (makelike|simple|custom) where makelike and simple just call the current cabal library routines and custom lets you specify a command that should be run and arguments passsed to it. (which can be something like 'runhaskell Setup.lhs') seperating cabal into its own program would also be a good place to provide a unified compiler independent 'runhaskell' script that can have logic for finding and running an appropirate compiler so people don't have to maintain an appropriate link to runhugs,runghc, or runjhc... while having a source code interface makes a lot of sense for single-source implementation-defined languages like perl, I think it is very inappropriate for multi-source, compiled programs. Especially when it gains you absolutly nothing other than headaches. The chance that someone will have such an absurdly odd build setup that one of the standard cabal models won't apply AND they can simulate the cabal interface exactly are virtually nil and if such a thing does exist, a build-style: custom will take care of it. You might not even have a haskell compiler on the system you want to run cabal on. (cross-compiling, bootstrapping) John -- John Meacham - ⑆repetae.net⑆john⑈
John Meacham
On Mon, Dec 12, 2005 at 03:14:09PM +0000, Duncan Coutts wrote:
On Mon, 2005-12-12 at 14:46 +0000, Simon Peyton-Jones wrote:
If the reason you want 6.6 is to get a new Cabal, why not download a new Cabal package? Or is there another reason you want 6.6?
That is exactly the problem. All non-trivial packages need a later version of Cabal since there are many many minor bug fixes and little feature additions in later versions of Cabal.
This is a large part of the reason I'd like to see cabal as a completly separate package from any compiler with a programatic interface rather than a library one. things will get very complicated when there are multiple major compilers and you have to tell users things like 'run runhaskell Setup.lhs, unless your runhaskell points to jhc, in which case do runghc Setup.lhs, oh, create a link from runhaskell to your proper compiler'.
To be fair, this isn't completely Cabal's fault. Perl, Python, bash, etc can all put #!/usr/bin/perl or whatever at the top of scripts. For Haskell we're not there yet and the fact that we have multiple major compilers is not really a good reason. I propose that each haskell compiler / interpreter come with runhaskell. It should check to see whether runhaskell exists already and if so, leave it alone. If not, provide it. That should probably be tweakable with the configure script. Whether Cabal comes w/ the compiler is invoked with runhaskell is a separate issue. For simplicity in bootstrapping, I think it should. Perl and Python also do it this way, as I understand.
We can do so without losing any flexability at all. just add a new line to the cabal file
build-style: (makelike|simple|custom)
where makelike and simple just call the current cabal library routines and custom lets you specify a command that should be run and arguments passsed to it. (which can be something like 'runhaskell Setup.lhs')
Simon pointed out one problem with this. I'm definitely thinking about relaxing the Setup.hs requirement, but I only want to do this once we understand the implications. Those implications will become more clear once we have things like cabal-install and cabal-get in active use. If almost everyone is using cabal-install and defaultMain, then a two-line tweak to cabal-install will relax the Setup.hs requirement.
seperating cabal into its own program would also be a good place to provide a unified compiler independent 'runhaskell' script that can have logic for finding and running an appropirate compiler so people don't have to maintain an appropriate link to runhugs,runghc, or runjhc...
I don't think this really has anything to do w/ Cabal, and I don't see why they should be bundled. There's certainly no logic in Cabal right now that'll make compiler preferences particularly easy to implement.
while having a source code interface makes a lot of sense for single-source implementation-defined languages like perl, I think it is very inappropriate for multi-source, compiled programs. Especially when it gains you absolutly nothing other than headaches. The chance that someone will have such an absurdly odd build setup that one of the standard cabal models won't apply AND they can simulate the cabal interface exactly are virtually nil and if such a thing does exist, a build-style: custom will take care of it.
As Simon pointed out, build-style: custom is implemented w/ hooks right now, and there are certainly programs out there using hooks, though not many of them. They're not particularly absurd build systems either.
You might not even have a haskell compiler on the system you want to run cabal on. (cross-compiling, bootstrapping)
You could always compile the setup script on the cross-compiling machine. I do like cabal-install, though, and I think that's the way of the future. peace, isaac
Isaac Jones
I propose that each haskell compiler / interpreter come with runhaskell. It should check to see whether runhaskell exists already and if so, leave it alone. If not, provide it.
Shouldn't replacement be the default? I think a typical user will stick with one Haskell implementation, and just upgrade it once in a while - in which case replacement is probably what is desired. Anyway, I expect most users to install via OS packages (rpm,deb,..), and distributions tend to have their own solutions for this kind of thing (/etc/alternatives springs to mind).
That should probably be tweakable with the configure script.
'runhaskell' could perhaps also be a small script that checks for the availability of 'runhugs', 'runghc', etc. This way, it could be the same for all Haskell implementations, and the choice could be configurable on a user basis (rather than per system). It would cost a bit of startup time, though. -k -- If I haven't seen further, it is by standing in the footprints of giants
Ketil Malde
'runhaskell' could perhaps also be a small script that checks for the availability of 'runhugs', 'runghc', etc. This way, it could be the same for all Haskell implementations, and the choice could be configurable on a user basis (rather than per system). It would cost a bit of startup time, though.
I have been thinking about extending 'hmake' with this functionality. 'hmake' already has a full infrastructure for configuring multiple compiler installations, so the 'runhaskell' script can be a very simple front-end over hmake - in fact the only difference is that it runs the generated executable in addition to building it. An experimental version is in hmake's CVS, called runhs.hs, if anyone wants to play with it. http://cvs.haskell.org/cgi-bin/cvsweb.cgi/nhc98/src/hmake/ The main thing currently missing from hmake is support for building with Hugs (mainly because it is a NOP), but a call to runhugs will be easy to add. Regards, Malcolm
On Thu, Dec 15, 2005 at 11:36:51AM +0000, Malcolm Wallace wrote:
I have been thinking about extending 'hmake' with this functionality. 'hmake' already has a full infrastructure for configuring multiple compiler installations, so the 'runhaskell' script can be a very simple front-end over hmake - in fact the only difference is that it runs the generated executable in addition to building it.
I'm not sure I understand correctly, but does that mean that hmake backed runhaskell could compile the application with (for example) GHC and reuse the binary for subsequent invocations (unless the code changes in the meantime, of course)? That would be prefect! Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland
Tomasz Zielonka
On Thu, Dec 15, 2005 at 11:36:51AM +0000, Malcolm Wallace wrote:
I have been thinking about extending 'hmake' with this functionality.
I'm not sure I understand correctly, but does that mean that hmake backed runhaskell could compile the application with (for example) GHC and reuse the binary for subsequent invocations (unless the code changes in the meantime, of course)?
Exactly so. Regards, Malcolm
Am Donnerstag, 15. Dezember 2005 09:21 schrieb Ketil Malde:
[...] Anyway, I expect most users to install via OS packages (rpm,deb,..), and distributions tend to have their own solutions for this kind of thing (/etc/alternatives springs to mind).
Yes, this is definitely the way to go. We should not try to duplicate existing functionality, probably in a much inferior way. All major Linux distributions (SuSE, Fedora, Debian, ...) use update-alternatives or a home-grown variation of this. Our OS packages should use this to existing mechanism and leave decisions like replacing or not to the underlying package manager and configuration files. I have to admit that I have been too lazy to fix the RPM .spec files in the repository to use update-alternative... :-] Let's see if I can find some time.
'runhaskell' could perhaps also be a small script that checks for the availability of 'runhugs', 'runghc', etc. This way, it could be the same for all Haskell implementations, and the choice could be configurable on a user basis (rather than per system). It would cost a bit of startup time, though.
That's again duplication: runhaskell is simply a link to the "real" executable and is under control of a cleanly separated mechanism like update-alternatives, no script hackery needed. The mechanism to make this configurable per-user is ~/bin/ and/or PATH, so there is no need to complicate things. I've been talking about Linux and *nix only above, but I'm sure other platforms have similar mechanisms. Cheers, S.
participants (9)
-
Duncan Coutts -
Ian Lynagh -
Isaac Jones -
John Meacham -
Ketil Malde -
Malcolm Wallace -
Simon Peyton-Jones -
Sven Panne -
Tomasz Zielonka