- Libraries - Haskell.org

official Cabal / Hackage wiki
by Isaac Jones 15 Dec '05

15 Dec '05

The new Cabal / Hackage wiki and bug tracking system is at: http://hackage.haskell.org/trac/hackage [1] Please report any Cabal (or HackageDB, cabal-get, etc) bugs there with "new ticket". Trac is pretty neat, you can inter-like wiki pages and tickets, as well as source code. Please feel free to start editing pages and adding information about Cabal. peace, isaac [1] Why the hackage...hackage redundancy? Well I'm basically hoping to roll out the "hackage" server as a community development site. As such, we have http://hackage.haskell.org/trac/ghc as well :)

1 0

RE: cabal release
by Simon Marlow 15 Dec '05

15 Dec '05

On 14 December 2005 01:28, Isaac Jones wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> I'd be rather happier if we could solve the versioning issue with >> Cabal, so that upgrading Cabal in the future doesn't automatically >> break code. It might not be possible to do this the first time >> around, but now is the time to design our way out of future >> problems. > > We need to experiment with stuff. People want to use the advanced > features like hooks on complex packages, but no one wants the > cabal-1.0 interface to hooks! We're trying to maintain a tension > between experimenting and providing something stabler for simple > programs (just like Haskell itself). It's bad if that breaks stuff, > but I don't want to end up in a situation where we tie ourselves to a > bad implementation because 3 packages used the old interface. I think > we just need to be better about explicitly stating what is stable and > what is not. Absolutely, I understand that. I'm not suggesting every tiny revision of the interface must be available for ever. But I think it would help a great deal if a Cabal release could support the previous, say, 1 or 2 major revisions of the interface, just to smooth the transition, so that a new release didn't automatically break a lot of packages. eg. Setup.lhs would do this: import Distribution_1_2.Simple main = defaultMain all we have to do is provide Distribution_1_2.*. When we freeze a version, we create a bunch of stubs under Distribution_<ver>, using explicit export lists everywhere. Sometimes we'll have to add some backwards compatibility code. The latest experimental version of the interface is always available as Distribution.* (or maybe Distribution_cur.*, or something), with appropriate warnings generated by DEPRECATED pragmas that the interface is subject to change. I've been thinking about adding support to Haddock to compare versions of interfaces and tell you what the changes are, this would be great for documentation and also to make sure that we aren't breaking interfaces. Cheers, Simon

1 0

RE: cabal release (was: cabal experiences)
by Simon Marlow 14 Dec '05

14 Dec '05

On 12 December 2005 15:31, Ian Lynagh wrote: > 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. I tend to agree. I'm not against breaking the rules in this case, since shipping Cabal-1.0 in 6.4.2 would be distinctly sub-optimal. Shipping two versions of Cabal is possible, but the build system isn't really set up to do this, so it's non-trivial work, and it still requires the user to say 'ghc-pkg expose Cabal-1.1.4; ghc-pkg hide Cabal-1.0'. Cabal is something of a special case, because its use is pretty much restricted to Setup.lhs scripts, which can be considered part of the build system rather than the code of a library or application. So this is build system API breakage, not library API breakage, m'lud ;-) I'd be rather happier if we could solve the versioning issue with Cabal, so that upgrading Cabal in the future doesn't automatically break code. It might not be possible to do this the first time around, but now is the time to design our way out of future problems. Cheers, Simon

2 1

RE: cabal release (was: cabal experiences)
by Simon Marlow 13 Dec '05

13 Dec '05

On 13 December 2005 02:33, John Meacham wrote: > 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') One usage of Setup.lhs that is becoming more common is to extend the simple build system in small ways using hooks. How do you envisage that working with your scheme? It looks like we would need to use "custom", but we're back to needing a to provide the build system as a library, otherwise every package needs to supply its own complete build system. I don't immediately see how this solves the problem, but perhaps I'm missing something. I'm not against eliminating Setup.lhs in the (common) case when it is just boilerplate. But we need to retain the ability to customise the simple build system, because it's both powerful and necessary. Cheers, Simon

1 0

Bugs in Graphics.HGL.Window and its documentation
by Kevin Van Horn 13 Dec '05

13 Dec '05

The function openWindowEx seems to ignore its second argument (optional initial position of window). Here is the test program to illustrate this, which I ran on Mac OS X (Tiger), using hugs: --- begin program --- import Graphics.HGL main = runGraphics $ do win <- openWindowEx "Test" (Just (200, 300)) (300, 300) Unbuffered Nothing ((x,y), (w,h)) <- getWindowRect win setGraphic win (text (100,100) (show (x,y) ++ " " ++ show (w,h))) getKey win closeWindow win --- end program --- Also, the documentation for the type RedrawMode (http:// www.haskell.org/ghc/docs/latest/html/libraries/HGL/Graphics-HGL- Window.html) seems to have the constructors Buffered and Unbuffered reversed.

3 2

RE: cabal release (was: cabal experiences)
by Simon Peyton-Jones 12 Dec '05

12 Dec '05

Why is it easier to get users to upgrade from GHC 6.4.1 to GHC 6.6 than it is to upgrade from Cabal 1.0 to Cabal 1.7 (say)? I must be missing something. S | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Duncan | Coutts | Sent: 12 December 2005 15:14 | To: Simon Peyton-Jones | Cc: libraries(a)haskell.org; Isaac Jones | Subject: RE: cabal release (was: cabal experiences) | | 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 | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

2 1

RE: Shipments in Cabal
by Simon Marlow 12 Dec '05

12 Dec '05

On 09 December 2005 19:50, Isaac Jones wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> I just made some changes to my proposal: >> >> http://haskell.org/hawiki/Cabal_2fAggregatePackages >> >> Mainly I made it so that the sub-packages don't have to be in a >> subdirectory, this means it will be easier to tar up the aggregate >> package. > > Can you clarify the terminology a bit? A distro package is an OS > package? Like RPM? Yes. > And a distributable is a kind of meta-package > that does nothing but depend on other packages? (If so, let's call it > a meta-package or something). No, by "distrutable" I meant a source distribution, i.e. whatever it is you grab from Hackage. > I like the idea of having a meta package that can be only > dependencies, but I don't think I really like the --local idea. I > don't really like the idea of one cabal package going to build another > package, invoking another setup script. I think that should be left > for layered tools. That's a shame, I thought it was quite cool :-( But I see your point. It seems slightly strange to be able to build *one* package using Setup.lhs, but as soon as I need to split my package into two I have to use some other tool to work on it. Not a big deal though. > Although I'm all for adding flags to cabal to allow packages to be > used in-place more effectively, I'd rather have a tool where I can > say: > > cabal-install: metapackage/metapackage.cabal --searchpath=. > > and maybe > > cabal-sdist metapackage/metapackage.cabal --searchpath=. > > will go and build .tar.gz files for everything it can find. That way > hackage won't have to change, it still works on the cabal-package > level. Ok, but remember we're only solving a problem that occurs for developers here. Users don't need to know about search paths - they just need to install a package and its dependencies. A developer, on the other hand, needs to be able to rebuild a set of packages in dependency order, without building everything each time. That is, the tool needs a way to ask for a rebuild, not just a full configure/build/install. And specifying the .cabal file for the metapackage isn't really enough: you should really go through the Setup.lhs script (it might have some optional dependencies, for example). > Incidentally, we would need to separate the concept of depends and > build-depends again, I guess. Remember that all build-depends cause > -package flags to be added to the command line of GHC. If these > dependencies are executables, then that's bad. Ok, I'm agnostic about depends. > Krasimir, would meta-packages and cabal-install solve the problems w/ > visual studio? We could add flags to cabal to improve in-place usage, > and to do something w/ a particular packageDB (though I want to figure > out a way to solve this for Hugs too). In-place usage is the main thing. If we can agree on --packagedb that's a step forward (simulating it with symlinks for Hugs?). This is the level that VS will hook into. Then as long as we have a way to build a set of packages in dependency order, without rebuilding everything each time, installing to a temporary location, I think the non-VS developer's needs will be met too. [snip] Cheers, Simon

1 0

RE: About cabal and compatibility
by Simon Marlow 12 Dec '05

12 Dec '05

On 11 December 2005 01:46, Isaac Jones wrote: > Robert Dockins <robdockins(a)fastmail.fm> writes: >> createVersionModule :: Version -> IO () >> createVersionModule version = do >> h <- openFile "src/Version.hs" WriteMode >> hPutStr h "module Version where\n" >> hPutStr h ("version = \""++(showVersion version)++"\"") >> hClose h > > That's interesting. I was recently thinking of generating something > like CabalInfo.hs which has information like the PackageDescription > and the LocalBuildInfo. You would turn on this feature w/ the .cabal > file. I'm not sure if any of the information is useful except for the > version number, though. This isn't necessary: you can get the version number from Paths_<pkg> (it's an undocumented feature :-). See the Cabalised Happy for an example. I should probably document it. Cheers, Simon

1 0

RE: About cabal and compatibility
by Simon Marlow 12 Dec '05

12 Dec '05

On 11 December 2005 00:38, Robert Dockins wrote: > The thing that got me thinking about it was Happy. Its recently been > put in a darcs, and Simon Marlow mentioned to me that they are > looking at moving to Cabal for the build system. > > The Happy build system now does two things that aren't your standard > build actions: > > 1) It creates module which contains the version string before > compilation 2) After compilation it runs CPP on a number of template > files with various different "-D" options to genreate the parser > templates. BTW, I recently Cabalised Happy. Get it from the darcs repo: darcs get http://darcs.haskell.org/happy Sorry you duplicated this work, I should have announced something, but I was holding off because it needed a very recent version of Cabal. Cheers, Simon

1 0

RE: About cabal and compatibility [Was: simplifying user hooks(non-backward-compatible)]
by Simon Marlow 12 Dec '05

12 Dec '05

On 10 December 2005 23:27, Robert Dockins wrote: > I just want to mention that these kind of changes represent represent > a VERY big problem. I agree, this is indeed a big problem. I've mentioned it before, albeit only briefly, and we didn't reach a conclusion. As you say, Cabal solves (for some value of solve) the versioning problem for everything except the Setup.lhs script itself. In the Setup.lhs script we have absolutely no way to request a particular version of the Cabal library, and even if you have the right version installed, it might not be the one used by default, so you're screwed ("runghc -package Cabal-1.0 Setup.lhs" doesn't work, and even if it did this would be a poor solution). The cabal-version field is only a partial solution - it doesn't help if the Cabal API changes such that your Setup.lhs script breaks. I support doing some explicit interface versioning along the lines of EternalCompatibiliyInTheory, but only for Cabal. It's extra work, but it's necessary if we want to be taken seriously. Cheers, Simon

1 0