February 2009 - cabal-devel

[Hackage] #289: symlink binaries into ~/bin
by Hackage 23 Apr '09

23 Apr '09

#289: symlink binaries into ~/bin ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Currently cabal-install uses `--prefix=$HOME/.cabal` and does not specify `--bindir` so we use `$HOME/.cabal/bin` as the bindir. Obviously this is not on the `$PATH` by default. It would be trivial to specify `--bindir=$HOME/bin` however the worry is that we would be stomping on programs that the user has already installed there. One solution is to continue to install into `$HOME/.cabal/bin` and then to make symlinks into `$HOME/bin` if the target name does not already exist. If the name does exist we could give a warning and let the user sort it out. Of course we need to be able to overwrite our own symlinks. We know it's a symlink we're allowed to overwrite if it links into `$HOME/.cabal/bin`. It would be nice to install into `$HOME/.cabal/bin` using versioned binary names (Cabal supports that now) and symlink the generic name into `$HOME/bin`. We can discover the names of the binary we're installing by checking the executable names in the `PackageDescription`. Of course this has to be an optional feature since not everyone wants it and there are no symlinks on windows. I'd imagine we'd have it in the `~/.cabal/config` file something like: {{{ prefix: $HOME/.cabal -- bindir: $HOME/.cabal/bin symlink-bindir: $HOME/bin }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/289> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 17

[Hackage] #453: "cabal fetch" should take output arguments
by Hackage 01 Apr '09

01 Apr '09

#453: "cabal fetch" should take output arguments ---------------------------------+------------------------------------------ Reporter: gregorycollins | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ It would be nice if "cabal fetch" could output the fetched tarball to a location specified on the command line, i.e.: cabal fetch bytestring -o foo.tgz This probably depends on #423. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/453> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #460: find the http proxy on windows more reliably
by Hackage 24 Mar '09

24 Mar '09

#460: find the http proxy on windows more reliably ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Some network setups (particularly corporate ones) do not use a static proxy set in the windows registry but use [http://msdn.microsoft.com/en- us/library/aa384240%28VS.85%29.aspx "AutoProxy"]. This is a rather complex protocol involving DHCP, dns and requires a !JavaScript interpreter. However the [http://msdn.microsoft.com/en- us/library/aa384273%28VS.85%29.aspx WinHTTP] library comes with Windows as of Win2k SP3, WinXP SP1, Win2k3 and Vista. It's got a bunch of functions for dealing with this AutoProxy stuff, [http://msdn.microsoft.com/en-us/library/aa384122(VS.85).aspx including sample code]. In particular the main function we want is [http://msdn.microsoft.com/en-us/library/aa384097(VS.85).aspx WinHttpGetProxyForUrl] So we could try either statically linking to this, or perhaps doing some dynamic !GetProcAddress funky stuff. Reading more closely, it seems that this only works if the setup is using an !AutoProxy setup. This documentation may be more relevant: * [http://msdn.microsoft.com/en-us/library/aa383660(VS.85).aspx Discovery Without an Auto-Config File] * [http://msdn.microsoft.com/en-us/library/aa384096(VS.85).aspx WinHttpGetIEProxyConfigForCurrentUser] * [http://msdn.microsoft.com/en-us/library/aa384095(VS.85).aspx WinHttpGetDefaultProxyConfiguration] It seems that there are some performance issues with !AutoProxy but any caching has to be fairly careful since the proxy information can change. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/460> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #451: dependency not listed on the hackageDB page
by Hackage 17 Mar '09

17 Mar '09

#451: dependency not listed on the hackageDB page --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | --------------------------------+------------------------------------------- The haskeline-0.6 package uses the terminfo package by default on POSIX systems. However, the hackageDB page for haskeline does not list terminfo as a possible dependency: http://hackage.haskell.org/cgi-bin/hackage- scripts/package/haskeline-0.5.0.1 -Judah -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/451> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #266: cabal haddock plus cpp preprocessing with relative #include files
by Hackage 17 Mar '09

17 Mar '09

#266: cabal haddock plus cpp preprocessing with relative #include files ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- All these bugs are against the homeomorphic library I have written. To play along, you can do darcs get --partial http://www.cs.york.ac.uk/fp/darcs/homeomorphic Bug 2: cabal haddock fails $ cabal haddock Preprocessing library homeomorphic-0.1... Running Haddock for homeomorphic-0.1... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: base-3.0.1.0, QuickCheck-1.1.0.0, mtl-1.1.0.0, containers-0.1.0.1 dist/build/tmp/Data/Homeomorphic/Hash1.hs:4:0: Include/Hash.hs: No such file or directory This one may well be my fault, if some extra magic is required for the haddock with CPP, but not the building - but that seems weird, if there is enough info to build the file, surely there is enough info to haddock it Duncan says: Right, there is no such guarantee at the moment. That's because ghc --make can find things by import chasing where Cabal needs more stuff specified explicitly. One day when Cabal does the import chasing they'll be consistent. In this case though it doesn't look like on of those problems. It seems to be because for haddock we're copying files to dist/ and then running cpp on them. That means of course that relative #includes do not work. It's not entirely clear to me why we are copying them before running cpp and not just running cpp on the files from their original locations. Please file a ticket for this one. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/266> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #188: file extensions
by Hackage 16 Mar '09

16 Mar '09

#188: file extensions --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.1 Platform: Linux | --------------------------+------------------------------------------------- GHC ignores Objective C sources unless -x c is passed to it on the command line before the source files. As far as I could tell there is no way to pass that option to GHC through Cabal so no .m files ever get built (well.. not completely true - setting ghc-options works but that breaks compilation of Haskell code). One way to get this to work would be to just add some extra code in Cabal to automatically pass -x c for .m files. This is probably a bad idea as someone might want or need to compile files using some other extension at some point. Another option is add some way of specifying compile options on a per-file (or group of files) basis: setting ghc-options to -x c just for one set of files. Still very limited but it's an improvement over the first option. Third option I can think of is to add a way of specifying compiler/extension pairs in Cabal so given compilers are automatically used to compile files with corresponding extensions. Depending on how much time I have I might look into adding this functionality myself but would like some feedback on which approach to take. Otherwise I might have to stick with autotools and ignore Cabal until it gets a bit more mature and flexible. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/188> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #381: broken link cabal user guide
by Hackage 11 Mar '09

11 Mar '09

#381: broken link cabal user guide ----------------------------------+----------------------------------------- Reporter: luntain | Owner: Type: defect | Status: new Priority: low | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: minor | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.3 Platform: | ----------------------------------+----------------------------------------- http://www.haskell.org/cabal/release/latest/doc/users-guide/builders.html #setup-test contains a broken link with label: Distribution.Simple the fragment which contais the link reads: "See Distribution.Simple for information about creating hooks and using defaultMainWithHooks." -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/381> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #380: Ability to blacklist packages that are on hackage
by Hackage 11 Mar '09

11 Mar '09

#380: Ability to blacklist packages that are on hackage ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: wishlist blacklist Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Sometimes there are packages on hackage that I don't want to install, perhaps ever. Maybe there is a buggy release I'm trying to avoid, or something of that nature. So, my proposal is a user defined blacklist. I think the version specification could work just like that of a .cabal file. I also think cabal should tell you when it skips a dependency due to blacklisting. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/380> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #471: check for ambigious module names
by Hackage 11 Mar '09

11 Mar '09

#471: check for ambigious module names ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Consider an example: {{{ build-depends: base, extensible-exceptions }}} The package `base-4.0.0.0` and `extensible-exceptions-0.1.1.0` both provide the module `Control.Exception`. This means it is impossible to pick both packages as direct dependencies of any single package. We should check for this situation at configure time and/or in cabal- install when planning an installation plan. Actually trying to avoid this situation may be rather tricky and it is not expected to occur often. So a simple check may be sufficient. If it starts to occur often in practice then we could consider trying to get the constraint solver to avoid the situation (perhaps by adding it to the checks for if a package is installable at all, see #420). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/471> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #503: "cabal haddock" should accept --hyperlink-sources (not just --hyperlink-source)
by Hackage 11 Mar '09

11 Mar '09

#503: "cabal haddock" should accept --hyperlink-sources (not just --hyperlink- source) ----------------------------+----------------------------------------------- Reporter: SamB | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I don't know how many times I've tried to pass it in the plural... it's getting annoying. What would the best way to get this to work be? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/503> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2