- cabal-devel - Haskell.org

API-tracker to check compliance with package versioning policy---advice please?
by Damon Wang 23 Mar '10

23 Mar '10

Hello everyone, I'm interested in writing the API-tracker described here http://hackage.haskell.org/trac/summer-of-code/ticket/1565 Mr. Marlow suggested I discuss it on the mailing list first. If this is the wrong list, I'm sorry, and I'd appreciate knowing where to find the correct one. This email consists of two parts: a high-level description of how I'd like to write the API-tracker, and the problems I encountered once I tried to bring that down to the level of actually writing code. I'd appreciate advice and criticism on both. >From the package versioning policy here http://www.haskell.org/haskellwiki/Package_versioning_policy it seems like the most foolproof way to validate a revised module's version number would be to diff the types of each exported symbol. There's a previous thread on this list by Laszlo Nagy suggesting that we query other services that might already have this information, but the replies seemed to be of the opinion that it would be better to have fewer dependencies. I assume if this is meant to validate submitted packages, read access to both before and after versions are guaranteed. What do people think of the overall strategy? Following the suggestion of using the existing introspection tools in GHC, I found the modInfoExports and modInfoLookupName functions. However, I'm having some trouble understanding the GHC API because http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-6.12.1/GHC.html only provides type information and sometimes a few cryptic comments. The other thing I've been trying is reading the Haddock source, because it's basically solving the same problem, right? Unfortunately, both efforts are stalling because I lack the necessary background knowledge of how GHC handles types. Is there a more verbose, newbie-friendly documentation that will answer questions like, "Suppose I have a function foo :: String -> String. How does GHC represent the type of this function?" I think http://hackage.haskell.org/trac/ghc/wiki/Commentary has the information I need to answer that question, or at least to read the GHC API reference. Unfortunately---you guessed it!---I don't know enough to understand the commentary. If all else fails, I supposed I'll just go post my questions in [beginners] or [haskell-cafe], but I'd prefer not to bother people unncessarily. In any case, thanks for your attention. I welcome any advice. Yours, Damon Wang

3 2

[Hackage] #647: Pretty printer for package descriptions is incomplete
by Hackage 21 Mar '10

21 Mar '10

#647: Pretty printer for package descriptions is incomplete ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- IDEs and other tools want to be able to parse, edit and then print out again .cabal files. The current pretty printer for the GenericPackageDescription is incomplete. The task is to complete the pretty printer so that we can correctly round trip parse/print. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/647> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #465: default global install on windows is a problem
by Hackage 21 Mar '10

21 Mar '10

#465: default global install on windows is a problem ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: Windows | ----------------------------+----------------------------------------------- Lots of windows users have problems installing things globally. Some are using multi-user systems. More are using Vista where it seems that even when they are running as administrator they cannot install files in `C:\Program Files\`. We should revisit the decision to install globally and see if we cannot find a default that works better. Failing by default is bad. We may also want to try to improve the checking beforehand to check if we would have permissions to write into the target directories. If not we can fail at configure time rather than waiting until install time and failing ungracefully. This needs someone who knows and cares about windows. Particularly for the Vista aspects. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/465> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

patch applied (cabal-branches/cabal-1.8): MERGE: Fix local inplace registration for ghc-6.12
by Duncan Coutts 21 Mar '10

21 Mar '10

Sun Mar 21 04:00:00 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * MERGE: Fix local inplace registration for ghc-6.12 Version of this patch for 1.8 branch that does not change external API. M ./Distribution/Simple/Build.hs -5 +16 M ./Distribution/Simple/Configure.hs -1 +5

1 0

patch applied (cabal-branches/cabal-install-0.8): Cope with intra-package deps when constructing install plans
by Duncan Coutts 21 Mar '10

21 Mar '10

Sat Mar 20 14:53:31 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Cope with intra-package deps when constructing install plans M ./Distribution/Client/Dependency/TopDown.hs -1 +3 M ./Distribution/Client/InstallPlan.hs -2 +3 A ./Distribution/Client/PackageUtils.hs M ./cabal-install.cabal +1

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 21 Mar '10

21 Mar '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: duncan Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Changes (by duncan): * owner: blackh => duncan * status: assigned => new Comment: Inspired by Stephen's patches I've committed these two fixes: {{{ Sat Mar 20 18:21:08 CET 2010 Duncan Coutts <duncan(a)haskell.org> * Fix local inplace registration for ghc-6.12 This is for the case of intra-package deps where the lib has to be registered into a local package db. We use "-inplace" suffix for the local installed package ids (rather than using an ABI hash). }}} And for cabal-install: {{{ Sat Mar 20 22:53:31 CET 2010 Duncan Coutts <duncan(a)haskell.org> * Cope with intra-package deps when constructing install plans }}} The main difference is that instead of trying to work out what the ABI hash of the inplace package is, we just use the package name with an "-inplace" suffix for the local inplace installed package ID. Needs a little testing then I'll push to the stable branches. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:30> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal-install): Cope with intra-package deps when constructing install plans
by Duncan Coutts 21 Mar '10

21 Mar '10

Sat Mar 20 14:53:31 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Cope with intra-package deps when constructing install plans M ./Distribution/Client/Dependency/TopDown.hs -1 +3 M ./Distribution/Client/InstallPlan.hs -2 +3 A ./Distribution/Client/PackageUtils.hs M ./cabal-install.cabal +1

1 0

patch applied (cabal): Factorise duplicate finding in package description checks
by Duncan Coutts 21 Mar '10

21 Mar '10

Sat Mar 20 14:51:32 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Factorise duplicate finding in package description checks M ./Distribution/PackageDescription/Check.hs -12 +17

1 0

patch applied (cabal): Fix local inplace registration for ghc-6.12
by Duncan Coutts 21 Mar '10

21 Mar '10

Sat Mar 20 10:21:08 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Fix local inplace registration for ghc-6.12 This is for the case of intra-package deps where the lib has to be registered into a local package db. We use "-inplace" suffix for the local installed package ids (rather than using an ABI hash). M ./Distribution/Simple/Build.hs -5 +13 M ./Distribution/Simple/Configure.hs -2 +2 M ./Distribution/Simple/LocalBuildInfo.hs +9

1 0

[Hackage] #639: 'source-repository' should not necessarily require 'cabal-version >= 1.6'
by Hackage 21 Mar '10

21 Mar '10

#639: 'source-repository' should not necessarily require 'cabal-version >= 1.6' ----------------------------+----------------------------------------------- Reporter: andersk | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- `Distribution.PackageDescription.Check` has this check: {{{ -- check use of "source-repository" section , checkVersion [1,6] (not (null (sourceRepos pkg))) $ PackageDistInexcusable $ "The 'source-repository' section is new in Cabal-1.6. " ++ "Unfortunately it messes up the parser in earlier Cabal versions " ++ "so you need to specify 'cabal-version: >= 1.6'." }}} However, I’ve found that Cabal 1.2 can successfully parse a cabal file with a 'source-repository' section (with a warning), _if_ that section is at the end of the file. Perhaps the check could be loosened to allow (and suggest) this? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/639> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2