- cabal-devel - Haskell.org

patch applied (cabal-branches/cabal-1.4): Add an --internal flag to HaddockFlags
by Duncan Coutts 05 May '08

05 May '08

Thu May 1 07:51:03 PDT 2008 Joachim Breitner <mail(a)joachim-breitner.de> * Add an --internal flag to HaddockFlags M ./Distribution/Simple/Setup.hs +9 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008050114…

1 0

patch applied (cabal): Cope better with ghc bug #2201, display a better error message
by Duncan Coutts 05 May '08

05 May '08

Mon May 5 01:57:46 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Cope better with ghc bug #2201, display a better error message Otherwise it can (and does) really confuse people. The problem is that the command $ ghc-pkg-6.9 describe '*' --user returns a non-zero exit code if the user package db is empty. ghc-pkg intends this exit code to tell us if the query returned any results (one can use more complex queries as tests) but Cabal interprets it as failure. Indeed we cannot distinguish it from any other kind of failure from ghc-pkg. M ./Distribution/Simple/GHC.hs -1 +11 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080505085746-adfee-30b21f3f…

1 0

patch applied (cabal): Add PackageIndex.dependencyCycles
by Duncan Coutts 04 May '08

04 May '08

Sun May 4 06:16:26 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add PackageIndex.dependencyCycles Finds any cycles (strongly connected components) in the dependencies of set of packages. This is useful for checking the correctness of installation plans. M ./Distribution/Simple/PackageIndex.hs +18 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080504131626-adfee-73906b09…

1 0

patch applied (cabal): Change dependencyInconsistencies to not take the pseudo top package
by Duncan Coutts 04 May '08

04 May '08

Sun May 4 06:08:02 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Change dependencyInconsistencies to not take the pseudo top package The one case where we need the pseudo top package we can use PackageIndex.insert instead to get the same effect and there are other cases in cabal-install where we do not want a pseudo top package. M ./Distribution/Simple/Configure.hs -1 +3 M ./Distribution/Simple/PackageIndex.hs -3 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080504130802-adfee-c3f2af9b…

1 0

patch applied (cabal): Reverse the order of the args to PackageIndex.insert
by Duncan Coutts 04 May '08

04 May '08

Sun May 4 06:03:17 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Reverse the order of the args to PackageIndex.insert To take the index last like the other functions and like Data.Map. It is actually more convenient that way round. M ./Distribution/Simple/PackageIndex.hs -2 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080504130317-adfee-b3c7de9a…

1 0

Re: Specifying dependencies on Haskell code
by Thomas Schilling 04 May '08

04 May '08

On 2 maj 2008, at 11.27, apfelmus wrote: > Duncan Coutts wrote: >> Thomas Schilling wrote: >>> >>> For example, if we write a program that uses the function >>> 'Foo.foo' contained in package 'foo' and we happen to have used >>> 'foo-0.42' for testing of our program. Then, given the >>> knowledge that 'Foo.foo' was introduced in 'foo-0.23' and >>> changed semantics in 'foo-2.0' then we know that 'foo >= 0.23 && >>> < 2.0' is the correct and complete dependency description. > > I would go even further and simply use "my program 'bar' compiles > with foo-0.42" as dependency description. In other words, whether > the package foo-0.23 can be used to supply this dependency or not > will be determined when somebody else tries to compile Bar with it. > > In both cases, the basic idea is that the library user should *not* > think about library versions, he just uses the one that is in scope > on his system. Figuring out which other versions can be substituted > is the job of the library author. In other words, the burden of > proof is shifted from the user ("will my program compile with > foo-1.1?") to the author ("which versions of my library are > compatible?"), where it belongs. I think we mean the same thing. If I write a program and test it against a specific version of a library then my program's source code and knowledge about which specific versions of libraries I used, most of the time, contains *all* the information necessary to determine which other library versions it can be built with. From the source code we need information about what is imported, from the library author we need a *formal* changelog. This changelog describes for each released version what part of the interface and semantics have changed. The problem here is, of course, that this is a lot of information to provide. Furthermore, I think we need information about imports from the library user, if we ignore this, then the PVP is *exactly* what we need. The PVP describes when things *could* break, but it does so in an extremely pessimistic way. If we have information about what exactly changed and what is used by a particular library, we can find out what the exact version range is. For example, if we build our package against foo-0.42 and bar-2.3 and both packages follow the PVP then the following will trivially be true: build-depends: foo-0.42.*, bar-2.3.* where "-X.Y.*" is a shortcut for ">= X.Y && < X.(Y+1)". The problem is that this is extremely pessimistic, so we have to manually check whenever a new version of a dependency comes out and update the "known-to-work-with"-range. With more information (obtained mostly by tools) we can automate this process, and, in fact, both approaches can co-exist. > >> However it would only help for the development _history_, we still >> have >> no solution for the problem of packages being renamed (or modules >> moving >> between packages) breaking other existing packages. Though >> similarly we >> have no solution to the problem of modules being renamed. Perhaps >> it's >> just that we have not done much module renaming recently so people >> don't >> see it as an issue. > > With the approach above, it's possible to handle package/module > renaming. For instance, if the package 'foo' is split into 'f-0.1' > and 'oo-0.1' at some point, we can still use the union of these two > to fulfill the old dependency 'foo-0.42'. This is kind of the same like using a "virtual package" that is simply a re-export of other packages. This would help a lot with our current problems with the base split (which will continue, as base will be split up even further). > > In other words, the basic model is that a module/package like 'bar' > with a dependency like 'foo-0.42' as just a function that maps a > value of the same type (= export list) as 'foo-0.42' to another > value (namely the set of exports of 'bar'). So, we can compile for > instance > > bar (foo-0.42) > > or > > bar (f-0.1 `union` oo-0.1) > > Of course, the problems are > > 1) specifying the types of the parameters, > 2) automatically choosing good parameters. > > For 1), one could use a very detailed import list, but I think that > this feels wrong. I mean, if I have to specify the imports myself, > why did I import foo-0.42 in the first place? Put differently, when > I say 'import Data.Map' I want to import both its implementation > and the interface. So, I argue that the goal is to allow type > specifications of the form 'same type as foo-0.42'. > > Problem 2) exists because if I have foo-0.5 on in scope on my > system and a package lists foo-0.42 as a dependency, the compiler > should somehow figure out that he can use foo-0.5 as argument. Of > course, it will be tricky/impossible to figure out that f-0.1 > `union` oo-0.1 is a valid argument, too. > > > So, the task would be to develop a formalism, i.e. some kind of > "lambda calculus for modules" that can handle problems 1) and 2). > The formalism should be simple to understand and use yet powerful, > just like our beloved lambda calculus. > > > A potential pitfall to any solution is that name and version number > don't identify a compiled package uniquely! For instance, > > foo-0.3 (bytestring-1.1) > > is very different from > > foo-0.3 (bytestring-1.2) > > if foo exports the ByteString type. That's the diamond import > problem. In other words, foo-0.3 is always the same function, but > the evaluated results are not. I think a formal changelog can also help with renaming (even of exported entities), but, I agree, for all this to work we need to formalise it first, and then build tools to automate most of the work. / Thomas -- My shadow / Change is coming. / Now is my time. / Listen to my muscle memory. / Contemplate what I've been clinging to. / Forty-six and two ahead of me.

2 1

Specifying dependencies on Haskell code
by Duncan Coutts 01 May '08

01 May '08

All, In the initial discussions on a common architecture for building applications and libraries one of the goals was to reduce or eliminate untracked dependencies. The aim being that you could reliably deploy a package from one machine to another. We settled on a fairly traditional model, where one specifies the names and versions of packages of Haskell code. An obvious alternative model is embodied in ghc --make and in autoconf style systems where you look in the environment not for packages but rather for specific modules or functions. Both models have passionate advocates. There are of course advantages and disadvantages to each. Both models seem to get implemented as reactions having the other model inflicted on the author. For example the current Cabal model of package names and versions was a reaction to the perceived problem of untracked dependencies with the ghc --make system. One could see implementations such as searchpath and franchise as reactions in the opposite direction. The advantages and disadvantages of specifying dependencies on module names vs package names and versions are mostly inverses. Module name clashes between packages are problematic with one system and not a problem with the other. Moving modules between packages is not a problem for one system and a massive pain for the other. The fact is that both module name and package name + version are being used as proxies to represent some vague combination of required Haskell interface and implementation thereof. Sometimes people intend only to specify an interface and sometimes people really want to specify (partial) semantics (eg to require a version of something including some bug fix / semantic change). In this situation the package version is being used to specify an implementation as a proxy for semantics. Neither are very good ways of identifying an interface or implementation/semantics. Modules do move from one package to another without fundamentally changing. Modules do change interface and semantics without changing name. There is no guarantee about the relationship between a package's version and its interface or semantics though there are some conventions. Another view would be to try and identify the requirements about dependent code more accurately. For example to view modules as functors and look at what interface they require of the modules they import. Then we can say that they depend on any module that provides a superset of that interface. It doesn't help with semantics of course. Dependencies like these are not so compact and easy to write down. I don't have any point here exactly, except that there is no obvious solution. I guess I'd like to provoke a bit of a discussion on this, though hopefully not just rehashing known issues. In particular if people have any ideas about how we could improve either model to address their weak points then that'd be well worth discussing. For example the package versioning policy attempts to tighten the relationship between a package version and changes in its interface and semantics. It still does not help at all with modules moving between packages. Duncan

2 2

Re: [Hackage] #156: setup haddock: option to expose all modules
by Hackage 01 May '08

01 May '08

#156: setup haddock: option to expose all modules ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: 1.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux ----------------------------------+----------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Joachim Breitner sent in patches for this: {{{ Thu May 1 15:51:03 BST 2008 Joachim Breitner <mail(a)joachim-breitner.de> * Add an --internal flag to HaddockFlags Thu May 1 16:24:21 BST 2008 Joachim Breitner <mail(a)joachim-breitner.de> * Implement --internal flag Passing --internal to the haddock stage does these things: * Does not pass --hide parameter to haddock * Passes --ignore-all-exports parameter * Appends "(internal documentation)" to the title Thu May 1 16:25:44 BST 2008 Joachim Breitner <mail(a)joachim-breitner.de> * With --executable, --internal just adds --ignore-all-exports Thu May 1 16:33:56 BST 2008 Joachim Breitner <mail(a)joachim-breitner.de> * Document --internal in Cabal.xml }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/156#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): Revert the change about the --internal flag and a warning about haddock
by Duncan Coutts 01 May '08

01 May '08

Thu May 1 15:31:31 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Revert the change about the --internal flag and a warning about haddock Just a bit of confusion over the behaviour of the --executable flag. M ./Distribution/Simple/Haddock.hs -3 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080501223131-adfee-a06a2a69…

1 0

patch applied (cabal): Document --internal in Cabal.xml
by Duncan Coutts 01 May '08

01 May '08

Thu May 1 08:33:56 PDT 2008 Joachim Breitner <mail(a)joachim-breitner.de> * Document --internal in Cabal.xml M ./doc/Cabal.xml +9 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080501153356-23c07-b5c9513f…

1 0