December 2008 - cabal-devel

[Hackage] #393: Allow --preference= flags for soft constraints
by Hackage 18 Dec '08

18 Dec '08

#393: Allow --preference= flags for soft constraints ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: cabal-install-0.6 Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ `cabal install` now uses soft preferences from a `preferred-versions` file in the hackage index. It would sometimes be useful to also be able to specify these on the command line. It shouldn't be too hard since the solver already accepts such soft- constraints. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/393> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

cabal-install sends invalid proxy password
by Valery V. Vorotyntsev 18 Dec '08

18 Dec '08

Dear lazy programmers, I was surprised to discover that `cabal-install' -- a popular utility for installing Hackage packages -- cannot work with HTTP proxies. Despite all the necessary code linked in. `cabal update' command returns HTTP 407 (Proxy Authentication Required) error. The problem is explained below and patches follow. * * * Our office LAN has an HTTP proxy server with authorization. And my shell environment has a variable like http_proxy='http://user:password@proxyhost:proxyport/' tcpdump-ing shows that `cabal update' sends invalid credentials in HTTP "CONNECT" request. The proper string would be "user:password" (base64-encoded) while `cabal' sends "user:password@". There's no surprise proxy server denies connection! I've traced the problem down to `userinfo' function, defined in network-2.2.0.1/Network/URI.hs:451: > -- RFC3986, section 3.2.1 > > userinfo :: URIParser String > userinfo = > do { uu <- many (uchar ";:&=+$,") > ; char '@' > ; return (concat uu ++"@") > } Let us see section 3.2 of RFC3986: > authority = [ userinfo "@" ] host [ ":" port ] > [... > ...] The user information, if present, is followed by a > commercial at-sign ("@") that delimits it from the host. There is no reason for "@" character to be a part of `userinfo' expression. * * * So, the Right Way(TM) to make cabal-install go through proxies is fixing `userinfo' function of `network' package (see the `network-2.2.0.1.patch'). Until then, we should have a workaround in `cabal-install' (cabal-install-0.6.0.patch). I do. Happy hacking! -- vvv

2 2

patch applied (cabal): Fix Show/Read for License
by Ian Lynagh 18 Dec '08

18 Dec '08

Fri Dec 12 10:36:22 PST 2008 Ian Lynagh <igloo(a)earth.li> * Fix Show/Read for License We were ending up with things like InstalledPackageInfo { ... license = LGPL Nothing, ... } i.e. "LGPL Nothing" rather than "LGPL", which we couldn't then read. M ./Distribution/License.hs -2 +14 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20081212183622-3fd76-d1f63fdf…

2 1

[Hackage] #402: Automatic hoogle database for installed packages
by Hackage 17 Dec '08

17 Dec '08

#402: Automatic hoogle database for installed packages ---------------------------------+------------------------------------------ Reporter: Peaker | 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.3 Platform: | ---------------------------------+------------------------------------------ The hoogle package is very useful to search the standard library. Unfortunately, it does not search packages that you have installed which are not part of the stdlib. It would be great if every package installed always had its haddock generated, and from its .txt file a .hoo file was generated (e.g: hoogle --convert), and then all .hoo files sat in some centralized directory which hoogle would then use for its searches. This would be great documentation, and let you hoogle for anything that you can import. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/402> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #431: Distribution.Make requires to use sudo and --global
by Hackage 16 Dec '08

16 Dec '08

#431: Distribution.Make requires to use sudo and --global ----------------------------+----------------------------------------------- Reporter: shelarcy | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: wxHaskell Difficulty: normal | Ghcversion: 6.10.1 Platform: | ----------------------------+----------------------------------------------- wxHaskell is heavily depends on self generated file. So, wxHaskell uses Distribution.Make to cabalize wxcore package now. But it causes trouble when using cabal command to install wxHaskell (wx and wxcore) from Hackage. Distribution.Make and cabal don't path any package databases options to configure script. So, we can't install wxHaskell (wx package) straightforward way. We must use following horrible command. {{{ sudo cabal install wxcore --global cabal install wx }}} See [http://sourceforge.net/tracker/index.php?func=detail&aid=2407551&group_id=7… wxHaskell's bug tracker #2407551] and [http://www.mail-archive.com /wxhaskell-devel(a)lists.sourceforge.net/msg00319.html wxhaskell-devel's thread]. Note: I tried to fix this problem by Custom Setup.lhs and Distribution.Make.WX. Attached file is that. But I can't get any package database information from Cabal and cabal. I checked configPackageDB flag's value by using unsafePerformIO. {{{ optPackageDB = unsafePerformIO (print (configPackageDB flag) >> return []) }}} It always shows just NoFlag. Neither supplying package database option and cabal command affect that. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/431> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #377: cabal install puts .hi files in wrong directory
by Hackage 16 Dec '08

16 Dec '08

#377: cabal install puts .hi files in wrong directory ----------------------------+----------------------------------------------- Reporter: cppljevans | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- On my unbuntu OS, cabal install catagory-extras put the files as shown here: <---cut here--- [ 99 of 100] Compiling Control.Morphism.Exo ( src/Control/Morphism/Exo.hs, dist/build/Control/Morphism/Exo.o ) [100 of 100] Compiling Control.Morphism.Meta.Erwig ( src/Control/Morphism/Meta/Erwig.hs, dist/build/Control/Morphism/Meta/Erwig.o ) /usr/bin/ar: creating dist/build/libHScategory-extras-0.53.5.a Installing library in /root/.cabal/lib/category-extras-0.53.5/ghc-6.8.2 Registering category-extras-0.53.5... Reading package info from "dist/installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. <---cut here--- whereas with manual install, they're put as shown here: <---cut here--- [12 of 12] Compiling Data.Generics.UniplateOn ( Data/Generics/UniplateOn.hs, dist/build/Data/Generics/UniplateOn.o ) /usr/bin/ar: creating dist/build/libHSuniplate-1.2.0.1.a /home/evansl/download/haskell/libs/uniplate-1.2.0.1 # runhaskell Setup install Installing library in /usr/local/lib/uniplate-1.2.0.1/ghc-6.8.2 Registering uniplate-1.2.0.1... Reading package info from "dist/installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. >---cut here--- When I compile with ghc, ghc cannot find the /root/.cabal files. If the -i flag is used, the files are found; however, another error occurs: <---cut here--- > make > ghc -i/root/.cabal/lib/category-extras-0.53.5/ghc-6.8.2 -c catamorphism.example.hs > > catamorphism.example.hs:19:0: > Bad interface file: /root/.cabal/lib/category- extras-0.53.5/ghc-6.8.2/Control/Functor/Fix.hi > Something is amiss; requested module main:Control.Functor.Fix differs from name found in the interface file category- extras-0.53.5:Control.Functor.Fix > make: *** [all] Error 1 >---cut here--- -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/377> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #340: Deprecate RecordPuns and translate NamedFieldPuns for older ghc
by Hackage 16 Dec '08

16 Dec '08

#340: Deprecate RecordPuns and translate NamedFieldPuns for older ghc ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.6 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- The `RecordPuns` extension was accidentally added. In ghc-6.10 it will be deprecated and done as an alias for `NamedFieldPuns`. See: http://hackage.haskell.org/trac/ghc/ticket/2320 That means people will use `NamedFieldPuns` instead which will then not work with older ghc. Cabal should encourage users to switch to `NamedFieldPuns` but should translate this into `RecordPuns` when calling older ghc versions. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/340> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #420: cabal-install upgrade optionally ignore packages that want a higher base?
by Hackage 16 Dec '08

16 Dec '08

#420: cabal-install upgrade optionally ignore packages that want a higher base? ----------------------------+----------------------------------------------- Reporter: jimburton | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- If I try to upgrade all packages it fails because syb wants a newer base: $ cabal upgrade Resolving dependencies... cabal: cannot configure syb-0.1.0.0. It requires base >=4.0 There is no available version of base that satisfies >=4.0 I don't want to upgrade GHC (in fact I can't right now) but I presume that there are other packages that could upgrade. Rather than run `cabal install' on them one by one, what about upgrading everything that is upgradeable, i.e. happy with the current base? There is a (misleading) analogy to the way apt treats releases -- it won't tell me "Can't upgrade because you're using the wrong release", but releases are self-contained and upgrades take place within that context...but obviously different because there you have different package lists for different releases... -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/420> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #390: add cabal unpack command
by Hackage 16 Dec '08

16 Dec '08

#390: add cabal unpack command ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ It'd be handy to be able to `cabal unpack` a package name. It would be useful for users to inspect or modify packages. {{{ $ cabal unpack blah }}} It would just unpack the cached tarball for that package into the current directory (which of course always creates a sub-directory). It should accept either a versioned or unversioned package name. If the package has not been fetched yet then cabal should probably fetch it. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/390> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #336: --constraint flag only used for configure not for install/upgrade dep planning
by Hackage 16 Dec '08

16 Dec '08

#336: --constraint flag only used for configure not for install/upgrade dep planning ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ It would be relatively easy to support the `--constraint=DEP` flag as an input to install/upgrade dependency planning. We should do it because it's useful and it's confusing that it's not supported. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/336> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3