January 2007 - cabal-devel

Using Cabal for dependancies
by Neil Mitchell 15 Jan '07

15 Jan '07

Hi, The Yhc compiler depends on an increasingly large number of Cabal packages - mtl and FilePath at the moment, but soon thats likely to increase by at least 3. Cabal is not yet mature enough to compile Yhc, and fitting in a compile of bits with Cabal will be quite hard because of the existing complexity in Scons. So what we'd really like to do is be able to call "cabal check-its-installed FilePath", which would return an appropriate exit code. If it wasn't installed then a darcs get, followed by a "cabal install-it-please" would be very handy. Does cabal-install provide the necessary bits for this? What is the result of installing a package that is already installed? How long til this kind of solution will be widely enough deployed that we can actually use it? Does anyone else have any other suggestions? Thanks Neil

2 3

Re: Multiple .cabal Files
by Henning Thielemann 13 Jan '07

13 Jan '07

Since the .installed-pkg-config and .setup-config files depend on the configure procedure and on the machine - shouldn't they be placed in 'dist', even more in a machine dependent sub-directory?

1 0

hackage projects for Hackathon
by Isaac Jones 09 Jan '07

09 Jan '07

Greetings! Many of you will be at the Hackathon tomorrow: http://www.haskell.org/haskellwiki/Hac_2007 I just did a brain-dump of what I think needs to get done to make cabal-install and hackage a reality. Much of the Hacking is already done and in good shape, but there are probably lots of little things to do, and there is work that needs to happen in order to gain adoption from the community. Here's my brain dump: http://hackage.haskell.org/trac/hackage/ticket/107 Of course, I'm not the only one with ideas, and others might have a lot of good ideas about what needs to be done. Above all, make it yours! Linked from the Hac 07 project page: http://www.haskell.org/haskellwiki/Hac_2007/Projects I'm going to try to be on IRC for some of the event, although the time of day isn't the best for me (since it starts at 2AM my time) :) peace, isaac

1 0

security/ experimental packages? authorization uncomon source locations, hackage db?
by Marc Weber 06 Jan '07

06 Jan '07

I've read the discussion about who is able to upload packages.. This is nice if you want to install most common packages.. But the packaging system is intended to save time. Thus what about I want to install an experimntal synthesizer which uses an experimental haskore interface from a person who hasn't registered his lib on hackage-db yet? In short: Would it be useful to allow speciyfing different download locations for dependencies in a cabal file? -- Lib.cabal -- depends: ExperimentalLib > 2.0 { location: http://person/haskell/ExperimentalLib.cabal } [...] This would give much more freedom .. I agree that it might be useful to "mask" those packages ... But its much more convinient to do cabal-install --allow-non-hackage-locations Lib than downloading/ installing/ updating those libs manually ? I think if you need total security you won't use this flag or use someithing like chroot (already mentioned) or user mode linux .. ;) But this issue adresses the question: What is hackage about: an automated installation system or an automated installation system + package list (centralized at hackagedb ?) Marc

1 0

where more info? comments on previous posts
by Marc Weber 06 Jan '07

06 Jan '07

Isaac showed me the Wiki. But I'm missing some pages discussing how hackage and tools should look like or pages which summarize decisions having be made on this list.. I think this missing because everything is in an early developement stage, right? What about adding some pages with summaries ? topics where I like to put my comment: 1) allow more than one atom beeing build with one cabal file? 2) configuration option, dependency handling ... a) different compilers / external dependencies b) proposal: flags my point of view c) hidden flags -> flag properties d) using availible libs e) posix os mingw cygwin detection? [4] f) build-profiles g) adding darcs-repository field to cabal h) external dependencies 1) allow more than one atom beeing build with one cabal file? ============================================================== "Cabal is the lowest-level tool for Haskell package management." I'd like to here some pro-cons about wether to allow putting libraries and executables into one cabal file: advantages multi atom cabal file: * it is one "Package" * one description/ license/ homepage field is sufficient * quote : "Configurations proposal On 10/24/06, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote: > > On the other hand, in Gtk2Hs I know one case where we do this. We have a > Graphics.UI.Gtk.Cairo api module that is only included if Gtk was built > against Cairo. In any case it could be faked by using cpp to just not > export anything rather than not having the module exposed at all. So > it's not clear that it's worth banning. Or maybe making it slightly > harder is worth it so that people don't get in the habit. Couldn't you split this into Gtk and Gtk-Cairo packages, where the latter is only built if Cairo is available? so it might be really useful to build more than one library using one package.. advantages single atom cabal file: * It does'nt make that much sense to me to allow different executables but only on lib. But allowing more than one lib will introduce another layer of abstraction as a cabal package is no longer the smallest unit. You need to check dependency within a cabal file and check dependencies not contained in cabal files * If you need library x you know you can find it in file x-version.cabal 2) configuration option, dependency handling ... ============================================================== a) different compilers versions ( see profile proposal below) Does it make sense to have more than one compiler version installed (eg ghc 6.4 6.5 and 6.6 ?) If so, whose task is to handle the different compilers? --with-hc-pkg=path --with-compiler=path or -wpath Would it make sense to have something like gcc/java-config of gentoo ? b) proposal: flags my point of view I'd like to see everything as flag. flags I'd like to add by default: - version - way = profiling | debug | optimized | distribution (user configurable ?) - stability (should be set by cabal readonly automatically) refering to [2] (build optimzed, profiling and debug version) and [3] (Duncan tells its intentional to not allow this) I agree. I'd like to be able to build different versions, too. That's why you have a packaging system that you don't have to all manually.. I yet have to look up how cabal does installing both profiling and default lib at the same time which was mentioned somewhere. One way to solve this is when building a profiling version append prof to its name. Thus if your lib L is build with profiling option it won't depend on parsec but on parsec-prof and won't be called L but L-prof. This way you have all you want, don't you? Cabal would have to add -prof option and add -prof to all names.. refering to [1]: Ian Lynagh: Why not permit declaration of flags insede a configuration? I can't see it why it should'nt be permitted c) hidden flags -> flag properties quote: " flag: fps_in_base dfault: available(base >= 2) " I like this idea (i had this tought too before reading this post) But I'd like to add "properties" to flags Thus what about: "hiden-flag: fps_in-base" ? This should mean the user can't modify it using configuration options.. d) using availible libs automatically refering to [http://www.haskell.org/pipermail/cabal-devel/2006-October/000230.html] ( On why 'availible' is evil) quote: "1. it often doesn't mean what you want 2. it allows auto-use deps 3. it makes life hard for distros and cabal-get 4. it makes the install order significant" comment to 1. If you have gtk and wxwidgets and you have the option to use either.. Then this would be a case I think its convinient to use the one already installed (?) But I agree that it wouldn't harm to set this option manually. So its cleaner to drop this auto-detection. Thanks for opening my eyes here! comment to 4. I agree. So what about determining library version which fits best independent of what can be found on the system, but add semething like emerge -p or emerge -va which tells you that lib xy is already installed having another version ? Thus if you have LibA-1.0 and wont to install LibB which would install LibA-2.0 on a plain new system I'd like to see dependencies to be installed: - LibA-2.0 (you already have 1.0, use -force-LibA-1.0 to use it) - ... This way installation order is not significant by default.. I've also read about binary packagers which don't like default flag values.. The same could be done here. Just print the automatically choosen flags and prompt for confirmation like this ./cabal-install LibA automacially determined dependencies: - LibB-2.0 unstable ( set by script, readonly) debug ( set by script, modifiable ) - haskell-db-2.0 (dependency of LibB) experimental ( set by script, readonly ) with-postgres : no with-mysql (set by command-line) with-Flat-DB (set by default) with-oracle : no - HSQL (dependency of haskell-db) with-postgres ( set by target haskell-db ) with-mysql (set by target haskell-db ) and optionally add configure option --no-defaults which prevents setting flags to default values Then everybody would be glad, right? e) posix os mingw cygwin detection? [4] Should os=windows be cygwin or mingw? no as os means operating system. mingw cygwin is no os but a build environment. I want to say it would be better to add another additional flag hasposix or is-mingw-build than changing os=windows to mingw/cygwin .. f) build-profiles What about build profiles? a build profile would consist of eg - compiler-flavour - compiler-version - flags (profile, debug, ..) - tools (use cpp = use c2hs = use greencard = ...) g) adding darcs-repository field to cabal If we talk about adding a darcs repo line to the cabal file it seems to me that cabal gets closer to maven which is a package management tool for java which handles * repositories * compilation * documentation * ide - integration (eclipse) * packaging * .. But there is one difference to cabal: It's sufficient to get the maven project description file if it contains information about how to get the source .. Thus: Does it make sense to distribute the cabal files with the source files? Why not add a general source-location: http://xy.z/.../source-2.3.tar.gz or source-location: darcs http://... line and the command ./setup fetch? but .. aeh this is the task of cabal-install, right? Sorry for this confusion.. I just don't understand yet why there are so many different tools and which task should be done by which tool.. h) external dependencies Some packages need foreign libraries (eg jnii Haskell-Java interface), (gtk/ wxwidgets) How to add them ??? i don't like to install some dependencies to notice that I also need C-lib xy .. Would it make sense to add support to install non-haskell libraries such as wxwidgets or sqlite as well ? Thus what about writing the system a little bit more general to also add a build profile for C-libraries? Unfortunately I've never used perl or CPAN.. ;( Does a page exist describing which features to implement form cpan? EG centralization ? CPAN seems to be mirrored and distributed all over the world. (But I might be wrong) Marc - sorry for this long mail quotes [1] ------------------------------------- Ian Lynagh igloo at earth.li Tue Oct 31 20:13:02 EST 2006 * Previous message: Configurations proposal * Next message: Configurations proposal * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] ----- Other bits A couple of other things occured to me. First, it should not be permitted to declare flags inside a configuration (I don't think anyone was saying otherwise, but I also don't think I saw it explicitly stated). [2] ------------------------------------- Configurations proposal Brian Smith brianlsmith at gmail.com Wed Oct 25 10:39:23 EDT 2006 On 10/24/06, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote: > > Hi All, > > Before the 6.6 release we had a longish discussion on how to do > configurations and their semantics and implementation complexity etc. > > I would like to re-propose the last scheme that I cam up with. I'll try > to make it a concrete proposal as well as giving some motivating > examples to give the intuition of the meaning. The only way I have really wanted to use configurations so far is to build debug, profiling, and optimized versions of a library. In order to build multiple configurations, is it going to still be the case that I have to "configure / build / install" separately for each configuration? I would like to be able to say something like "Setup.lhs configure --optimized --debug --profiled" to build all three versions at once. [3] ------------------------------------------ Duncan Coutts duncan.coutts at worc.ox.ac.uk Wed Oct 25 13:56:24 EDT 2006 * Previous message: Configurations proposal * Next message: Configurations proposal * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > How can I say that I want the DEBUG version of package "bar" to depend > on the DEBUG version of package "foo."? Is this allowed? No. This is not allowed. Indeed you can't express it with the syntax. That's because we don't record which configurations were active for a package that was built. This is intentional. [4] Brian Smith brianlsmith at gmail.com Thu Oct 26 11:52:48 EDT 2006 * Previous message: Configurations proposal * Next message: Configurations proposal * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [...] I agree--I wish System.Info.os worked differently, actually. But, there are apparently some people (not me) that use Haskell on Cygwin, and they need to be able to detect it, because e.g. Posix and Readline are available on Cygwin but not Mingw. Maybe os(x) should be either "mingw" or "cygwin"? - Brian [4] ---------------------------------- Configurations proposal Duncan Coutts duncan.coutts at worc.ox.ac.uk Tue Oct 31 20:34:35 EST 2006 > flag: fps_in_base > default: available(base >= 2) > > configuration: fps_in_base > build-depends: base(>= 2) > > configuration: !fps_in_base > build-depends: base(< 2), fps > > The user would be able to shoot themselves in the foot by overidding the > fps_in_base flag such that they don't have the deps installed, but > that's their own fault. Note that the right thing will happen if they > just leave it as the default. Yeah it'd work but I don't like it. It exposes too much to the user for one thing. It's not always going to do the the right thing either. In this case you can only have one version of base installed at once, but for other libs that's not the case. So imagine I do have base-1.0 and 2.0 installed then there's no

1 0

darcs patch: Add preliminary support for haddock-ghc (and 2 more)
by davve＠dtek.chalmers.se 04 Jan '07

04 Jan '07

Fri Sep 15 21:29:49 CEST 2006 davve(a)dtek.chalmers.se * Add preliminary support for haddock-ghc Fri Dec 29 20:54:39 CET 2006 davve(a)dtek.chalmers.se * Make sure haddock-ghc really creates the output dir Sun Dec 31 00:21:16 CET 2006 davve(a)dtek.chalmers.se * Add compilerPath to Paths_<pkg>

1 0

Re: [David Waern] Re: darcs patch: Add preliminary support for haddock-ghc
by Neil Mitchell 01 Jan '07

01 Jan '07

Hi, > No, it doesn't work yet. So I turn the question around: Will GADT's and > other extensions be supported by Hoogle in the future? To some degree, yes. A GADT will probably be recorded as though it was a normal ADT for type matching purposes. It's similar with forall at the moment, they are entirely dropped for type matching purposes, but are searched. > Without such > support, how useful would it be to include Hoogle support in haddock-ghc? I would have thought quite useful, for example if you are going to hoogle something like Yampa, you'll need something which can at least ignore the GADT's. My larger concern was if haddock-ghc is going to replace haddock one day, then I'll definately want --hoogle in there. Thanks Neil

1 0