From Malcolm.Wallace at cs.york.ac.uk Thu May 1 06:02:52 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu May 1 06:04:04 2008 Subject: patch applied (cabal): Change handling of bool command line args to allow an unset state In-Reply-To: <20080430115506.GA636@haskell.galois.com> References: <20080430115506.GA636@haskell.galois.com> Message-ID: <20080501110252.453e8a91.Malcolm.Wallace@cs.york.ac.uk> > Tue Apr 29 13:11:23 PDT 2008 Duncan Coutts > * Change handling of bool command line args to allow an unset state > For bool valued flags we were always producing the command line > string corresponding to a false flag value, even if the flag was > not set. For example we'd always get "--disable-shared". > It is important for cabal-install to be able to take an empty set > of flags, override a few flags and turn the flags back into > command line strings without getting a lot of extra defaults. > Partly this is because we have to work with older versions of the > Cabal library command line which does not recognise the new options. This patch breaks the nhc98 build of Cabal. Here is the error: $ /Users/malcolm/Haskell/nhc98/script/nhc98 -c Distribution/Simple/Command.hs nhc98comp: The class Prelude.Functor has no instance for the type Prelude.->. Possible sources for the problem are: 189:72-189:75 When type checking declarations at: 189:1-189:81 And the offending lines of the patch: hunk ./Distribution/Simple/Command.hs 188 -boolOpt' :: (b -> Bool) -> (Bool -> b) -> OptFlags -> OptFlags -> MkOptDescr (a -> b) (b -> a -> a) a -boolOpt' g s ffT ffF _sf _lf d get set = BoolOpt d ffT ffF (set.s) (g.get) +boolOpt' :: (b -> Maybe Bool) -> (Bool -> b) -> OptFlags -> OptFlags -> MkOptDescr (a -> b) (b -> a -> a) a +boolOpt' g s ffT ffF _sf _lf d get set = BoolOpt d ffT ffF (set.s) (g `fmap` get) Regards, Malcolm From duncan.coutts at worc.ox.ac.uk Thu May 1 06:49:36 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 1 06:43:21 2008 Subject: patch applied (cabal): Change handling of bool command line args to allow an unset state In-Reply-To: <20080501110252.453e8a91.Malcolm.Wallace@cs.york.ac.uk> References: <20080430115506.GA636@haskell.galois.com> <20080501110252.453e8a91.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <1209638976.30059.196.camel@localhost> On Thu, 2008-05-01 at 11:02 +0100, Malcolm Wallace wrote: > This patch breaks the nhc98 build of Cabal. Here is the error: > > $ /Users/malcolm/Haskell/nhc98/script/nhc98 -c Distribution/Simple/Command.hs > nhc98comp: The class Prelude.Functor has no instance for the type Prelude.->. > Possible sources for the problem are: 189:72-189:75 > When type checking declarations at: 189:1-189:81 > > And the offending lines of the patch: > > hunk ./Distribution/Simple/Command.hs 188 > -boolOpt' :: (b -> Bool) -> (Bool -> b) -> OptFlags -> OptFlags -> MkOptDescr (a -> b) (b -> a -> a) a > -boolOpt' g s ffT ffF _sf _lf d get set = BoolOpt d ffT ffF (set.s) (g.get) > +boolOpt' :: (b -> Maybe Bool) -> (Bool -> b) -> OptFlags -> OptFlags -> MkOptDescr (a -> b) (b -> a -> a) a > +boolOpt' g s ffT ffF _sf _lf d get set = BoolOpt d ffT ffF (set.s) (g `fmap` get) Thanks. Fixed. Thu May 1 11:46:20 BST 2008 Duncan Coutts * Revert one change of (.) to fmap. It was not necessary and broke nhc98. The other one was needed as we changed a type from Bool to Maybe Bool. Duncan From duncan.coutts at worc.ox.ac.uk Thu May 1 06:48:58 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 1 06:43:23 2008 Subject: patch applied (cabal): Revert one change of (.) to fmap. It was not necessary and broke nhc98. Message-ID: <20080501104858.GA1575@haskell.galois.com> Thu May 1 03:46:20 PDT 2008 Duncan Coutts * Revert one change of (.) to fmap. It was not necessary and broke nhc98. The other one was needed as we changed a type from Bool to Maybe Bool. M ./Distribution/Simple/Command.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080501104620-adfee-b0c0ab8837d653a2972a8c07d92a703cc6b92020.gz From Malcolm.Wallace at cs.york.ac.uk Thu May 1 07:01:31 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu May 1 06:55:58 2008 Subject: patch applied (cabal): Revert the other `fmap` to (.) Message-ID: <20080501110131.GA1929@haskell.galois.com> Thu May 1 04:00:06 PDT 2008 Malcolm.Wallace@cs.york.ac.uk * Revert the other `fmap` to (.) To avoid needing a non-H'98 instance of Functor for (->). M ./Distribution/Simple/Command.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080501110006-6871e-3c8af0e15b9a8c8ce1528409be74bd79bb3e1d67.gz From ross at soi.city.ac.uk Thu May 1 07:44:13 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu May 1 07:38:41 2008 Subject: patch applied (cabal): Revert the other `fmap` to (.) In-Reply-To: <20080501110131.GA1929@haskell.galois.com> References: <20080501110131.GA1929@haskell.galois.com> Message-ID: <20080501114413.GA2786@soi.city.ac.uk> On Thu, May 01, 2008 at 04:01:31AM -0700, Malcolm Wallace wrote: > Thu May 1 04:00:06 PDT 2008 Malcolm.Wallace@cs.york.ac.uk > * Revert the other `fmap` to (.) > To avoid needing a non-H'98 instance of Functor for (->). > > M ./Distribution/Simple/Command.hs -1 +1 I'm puzzled as to why nhc98 lacks this instance in this module, given the import chain Distribution.Simple.Command -> Distribution.ParseUtils -> Data.Tree -> Control.Applicative -> Control.Monad.Instances From Malcolm.Wallace at cs.york.ac.uk Thu May 1 10:51:13 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu May 1 10:50:16 2008 Subject: patch applied (cabal): Revert the other `fmap` to (.) In-Reply-To: <20080501114413.GA2786@soi.city.ac.uk> References: <20080501110131.GA1929@haskell.galois.com> <20080501114413.GA2786@soi.city.ac.uk> Message-ID: <20080501155113.10362b5f.Malcolm.Wallace@cs.york.ac.uk> Ross Paterson wrote: > > To avoid needing a non-H'98 instance of Functor for (->). > > I'm puzzled as to why nhc98 lacks this instance in this module, > given the import chain > > Distribution.Simple.Command > -> Distribution.ParseUtils > -> Data.Tree > -> Control.Applicative > -> Control.Monad.Instances nhc98 has a performance hack to avoid dumping large numbers of instance decls into .hi interface files. For any given instance, if both the class and the type are defined in the Prelude, then the instance can be omitted from the interface file (for any module except the Prelude itself), under the assumption that it will already be available by default via the Prelude, which is implicitly imported everywhere anyway. This assumption is entirely reasonable for H'98. But non-H'98 modules that add new instances for Prelude types and classes break the assumption. There is a workaround: essentially every non-Prelude module that is intended to define or re-export such non-standard instances, can tell the compiler to pretend it is building the Prelude, and so should include all instances in the interface. The flag is {-# OPTIONS_NHC98 --prelude #-}. The awkward part is that you need to add that line to _every_ module in the chain you gave above. Regards, Malcolm From ross at soi.city.ac.uk Thu May 1 11:08:10 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu May 1 11:02:39 2008 Subject: patch applied (cabal): Revert the other `fmap` to (.) In-Reply-To: <20080501155113.10362b5f.Malcolm.Wallace@cs.york.ac.uk> References: <20080501110131.GA1929@haskell.galois.com> <20080501114413.GA2786@soi.city.ac.uk> <20080501155113.10362b5f.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20080501150810.GA3337@soi.city.ac.uk> On Thu, May 01, 2008 at 03:51:13PM +0100, Malcolm Wallace wrote: > nhc98 has a performance hack to avoid dumping large numbers of instance > decls into .hi interface files. For any given instance, if both the > class and the type are defined in the Prelude, then the instance can be > omitted from the interface file (for any module except the Prelude > itself), under the assumption that it will already be available by > default via the Prelude, which is implicitly imported everywhere anyway. > This assumption is entirely reasonable for H'98. > > But non-H'98 modules that add new instances for Prelude types and > classes break the assumption. I don't think it is reasonable. There is nothing in H98 that forbids defining instances for Prelude types and classes, as long as they don't get into modules defined in the H98 Report. Open world and all that. From trac at galois.com Thu May 1 13:19:09 2008 From: trac at galois.com (Hackage) Date: Thu May 1 13:13:33 2008 Subject: [Hackage] #273: Provide a stable address for current Haddock documentation Message-ID: <042.482a994d31ad3a5a48cd5fc873de4683@localhost> #273: Provide a stable address for current Haddock documentation ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Documentation for version 0.1.1 of the Derive package is at http://hackage.haskell.org/packages/archive/derive/0.1.1/doc/html/ - but as soon as I upload a new version any documentation links will become out of date. It would be very useful if there was a stable URL where the documentation of the latest version of a package could be found. -- Neil Mitchell -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Thu May 1 17:48:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 1 17:43:14 2008 Subject: patch applied (cabal-branches/cabal-1.4): Revert one change of (.) to fmap. It was not necessary and broke nhc98. Message-ID: <20080501214848.GA14960@haskell.galois.com> Thu May 1 03:46:20 PDT 2008 Duncan Coutts * Revert one change of (.) to fmap. It was not necessary and broke nhc98. The other one was needed as we changed a type from Bool to Maybe Bool. M ./Distribution/Simple/Command.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080501104620-adfee-b0c0ab8837d653a2972a8c07d92a703cc6b92020.gz From duncan.coutts at worc.ox.ac.uk Thu May 1 17:48:50 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 1 17:43:14 2008 Subject: patch applied (cabal-branches/cabal-1.4): Revert the other `fmap` to (.) Message-ID: <20080501214850.GA14983@haskell.galois.com> Thu May 1 04:00:06 PDT 2008 Malcolm.Wallace@cs.york.ac.uk * Revert the other `fmap` to (.) To avoid needing a non-H'98 instance of Functor for (->). M ./Distribution/Simple/Command.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080501110006-6871e-3c8af0e15b9a8c8ce1528409be74bd79bb3e1d67.gz From trac at galois.com Thu May 1 17:50:00 2008 From: trac at galois.com (Hackage) Date: Thu May 1 17:44:23 2008 Subject: [Hackage] #268: cabal upload asks for a password in plain text In-Reply-To: <042.194090d9016445d7e9ae4a0e3ba60d0f@localhost> References: <042.194090d9016445d7e9ae4a0e3ba60d0f@localhost> Message-ID: <051.5fbad67b488f0312739188ce255dd26f@localhost> #268: cabal upload asks for a password in plain text ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: fixed Keywords: | Difficulty: very easy (<1 hour) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Done. {{{ Thu May 1 22:44:56 BST 2008 Duncan Coutts * Don't echo when prompting for the hackage upload password. Fixes ticket #268. And use newtypes for the username and password, just to be more sure we're not mixing them up with other strings. }}} So it doesn't echo '*'s instead it just turns off terminal echoing which hopefully is more portable. We still use getLine rather than getChar so that uses the OS/terminal's line editing facilities which means you can still use backspace etc. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Thu May 1 17:50:03 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 1 17:44:25 2008 Subject: patch applied (cabal-install): Don't echo when prompting for the hackage upload password. Message-ID: <20080501215002.GA15063@haskell.galois.com> Thu May 1 14:44:56 PDT 2008 Duncan Coutts * Don't echo when prompting for the hackage upload password. Fixes ticket #268. And use newtypes for the username and password, just to be more sure we're not mixing them up with other strings. M ./Hackage/Config.hs -6 +6 M ./Hackage/Setup.hs -4 +7 M ./Hackage/Types.hs -2 +2 M ./Hackage/Upload.hs -8 +21 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080501214456-adfee-d7d71bfe53f413ae92eae0f8bcdb307fb9227239.gz From trac at galois.com Thu May 1 18:11:43 2008 From: trac at galois.com (Hackage) Date: Thu May 1 18:06:08 2008 Subject: [Hackage] #267: cabal upload has poor error messages (just an HTTP response code) In-Reply-To: <042.7406bd491a8ebc93e9f9e327d9e092d9@localhost> References: <042.7406bd491a8ebc93e9f9e327d9e092d9@localhost> Message-ID: <051.284527531755a2854c7d941657be6aea@localhost> #267: cabal upload has poor error messages (just an HTTP response code) ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Replying to [comment:2 ross]: > OK, I can bypass outputError and send the plain text on request. Then cabal upload can stop ignoring it. That'd be great. At the moment we're sending `Accept: text/plain` and getting `Content- Type: text/html; charset=ISO-8859-1` as a response. As a note to whoever wants to do the client-side change in future: inspect {{{ [ s | Header HdrContentType s <- rspHeaders resp ] }}} to see if it starts with `"text/plain"` and if so print the `rspBody resp` -- Ticket URL: Hackage Hackage: Cabal and related projects From nominolo at googlemail.com Thu May 1 18:28:52 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu May 1 18:23:25 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> Message-ID: <1CF77D06-B9B3-4582-A6C5-21A1052F01D4@googlemail.com> On 20 apr 2008, at 22.22, Duncan Coutts wrote: > 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 > [Replying so late as I only saw this today.] I believe that using tight version constraints in conjunction with the PVP to be a good solution. For now. I don't quite know how Searchpath works (the website is rather taciturn), but I think that we should strive for a better approximation to real dependencies, specifically, name, interface, and semantics of imported functions. As I see it, what's missing is proper tool support to do it practically for both library authors and users. Library users really shouldn't need to do anything except to run a tool to determine all dependencies of a given package. Library authors should be able to run a tool that determines what's new and what might have changed. The package author then merely decides whether semantics was changed and if so, in what way (i.e., compatible or not to previous semantics). Packages will still carry versions, but they are only used to mark changes. Semantic information is provided via a "change database" which contains enough information to determine whether a version of a package contains appropriate implementations of the functions (or, more generally, entities) used in a dependent package. 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. That's the ideal, maybe we can work towards this? Or does this sound crazy? / Thomas -- "Today a young man on acid realized that all matter is merely energy condensed to a slow vibration, that we are all one consciousness experiencing itself subjectively, there is no such thing as death, life is only a dream, and we are the imagination of ourselves." -- Bill Hicks -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080502/d52106e0/PGP.bin From duncan.coutts at worc.ox.ac.uk Thu May 1 18:55:56 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 1 18:50:20 2008 Subject: patch applied (cabal): Add an --internal flag to HaddockFlags Message-ID: <20080501225556.GA16284@haskell.galois.com> Thu May 1 07:51:03 PDT 2008 Joachim Breitner * Add an --internal flag to HaddockFlags M ./Distribution/Simple/Setup.hs +9 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080501145103-23c07-6467705161f8b10d3fd1e94d50c15b2f5f749aa7.gz From duncan.coutts at worc.ox.ac.uk Thu May 1 18:55:58 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 1 18:50:24 2008 Subject: patch applied (cabal): Implement --internal flag Message-ID: <20080501225557.GA16307@haskell.galois.com> Thu May 1 08:24:21 PDT 2008 Joachim Breitner * 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 M ./Distribution/Simple/Haddock.hs -4 +13 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080501152421-23c07-49770b4462ef8c24e3657ea47bda7db4be59e75d.gz From duncan.coutts at worc.ox.ac.uk Thu May 1 18:55:59 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 1 18:50:25 2008 Subject: patch applied (cabal): With --executable, --internal just adds --ignore-all-exports Message-ID: <20080501225559.GA16324@haskell.galois.com> Thu May 1 08:25:44 PDT 2008 Joachim Breitner * With --executable, --internal just adds --ignore-all-exports M ./Distribution/Simple/Haddock.hs -1 +6 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080501152544-23c07-e4deafe31ec21b6e8076149277330eca2bcf99c2.gz From duncan.coutts at worc.ox.ac.uk Thu May 1 18:56:01 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 1 18:50:26 2008 Subject: patch applied (cabal): Document --internal in Cabal.xml Message-ID: <20080501225601.GA16341@haskell.galois.com> Thu May 1 08:33:56 PDT 2008 Joachim Breitner * Document --internal in Cabal.xml M ./doc/Cabal.xml +9 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080501153356-23c07-b5c9513f0088d5a64fbf95ba6dc8961162f92952.gz From duncan.coutts at worc.ox.ac.uk Thu May 1 18:56:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 1 18:50:27 2008 Subject: patch applied (cabal): Revert the change about the --internal flag and a warning about haddock Message-ID: <20080501225602.GA16358@haskell.galois.com> Thu May 1 15:31:31 PDT 2008 Duncan Coutts * 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-a06a2a6941538589bbfee6f241df4973ec867bfc.gz From trac at galois.com Thu May 1 19:06:48 2008 From: trac at galois.com (Hackage) Date: Thu May 1 19:01:51 2008 Subject: [Hackage] #156: setup haddock: option to expose all modules In-Reply-To: <056.346b3ee6f7fee0d65f5b09ec05a21ea6@localhost> References: <056.346b3ee6f7fee0d65f5b09ec05a21ea6@localhost> Message-ID: <065.90f13648314a75a14020184e80a3600d@localhost> #156: setup haddock: option to expose all modules ----------------------------------+----------------------------------------- Reporter: ross@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 * Add an --internal flag to HaddockFlags Thu May 1 16:24:21 BST 2008 Joachim Breitner * 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 * With --executable, --internal just adds --ignore-all-exports Thu May 1 16:33:56 BST 2008 Joachim Breitner * Document --internal in Cabal.xml }}} -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Thu May 1 19:16:50 2008 From: trac at galois.com (Hackage) Date: Thu May 1 19:11:13 2008 Subject: [Hackage] #267: cabal upload has poor error messages (just an HTTP response code) In-Reply-To: <042.7406bd491a8ebc93e9f9e327d9e092d9@localhost> References: <042.7406bd491a8ebc93e9f9e327d9e092d9@localhost> Message-ID: <051.a9011d3b957605d721c17925de7f34ec@localhost> #267: cabal upload has poor error messages (just an HTTP response code) ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by ross): Replying to [comment:3 duncan]: > At the moment we're sending `Accept: text/plain` and getting `Content- Type: text/html; charset=ISO-8859-1` as a response. That is done by `outputError` in the cgi package. Bj?rn Bringert is rewriting `outputError` and friends to check HTTP_ACCEPT and send the error messages as text/plain if requested. When that's done, the server side will require only a recompile. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Thu May 1 19:49:37 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 1 19:43:20 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <1CF77D06-B9B3-4582-A6C5-21A1052F01D4@googlemail.com> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <1CF77D06-B9B3-4582-A6C5-21A1052F01D4@googlemail.com> Message-ID: <1209685777.30059.228.camel@localhost> On Fri, 2008-05-02 at 00:28 +0200, Thomas Schilling wrote: > On 20 apr 2008, at 22.22, Duncan Coutts wrote: > [Replying so late as I only saw this today.] > > I believe that using tight version constraints in conjunction with > the PVP to be a good solution. For now. I think I tend to agree. > I don't quite know how Searchpath works (the website is rather > taciturn), but I think that we should strive for a better > approximation to real dependencies, specifically, name, interface, > and semantics of imported functions. As I see it, what's missing is > proper tool support to do it practically for both library authors and > users. Yes, we can make package name and version a better approximation of the package interface with tools to enforce the versioning policy. > Library users really shouldn't need to do anything except to run a > tool to determine all dependencies of a given package. Library > authors should be able to run a tool that determines what's new and > what might have changed. The package author then merely decides > whether semantics was changed and if so, in what way (i.e., > compatible or not to previous semantics). Packages will still carry > versions, but they are only used to mark changes. Semantic > information is provided via a "change database" which contains enough > information to determine whether a version of a package contains > appropriate implementations of the functions (or, more generally, > entities) used in a dependent package. > > 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. > > That's the ideal, maybe we can work towards this? > Or does this sound crazy? I think extracting package APIs and comparing them across versions is an excellent thing to do. It'd help users see what has changed and it'd let us enforce the versioning policy (at least for interface changes, not for semantic changes). Having a central collection of those interfaces and using that to work out which versions of which packages would be compatible with the program I just wrote is quite an interesting idea. It's related to what I was saying about identifying code by it's full interface, as a functor, but then using that to map back to packages that provide the interface. Something like that might go some way to addressing David Roundy's quite legitimate criticism that the system of specifying deps on package names and versions requires one to know the full development history of that code, eg to track it across package renames. 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. Duncan From trac at galois.com Fri May 2 17:25:24 2008 From: trac at galois.com (Hackage) Date: Fri May 2 17:19:44 2008 Subject: [Hackage] #265: Cabal field stability not useful In-Reply-To: <042.a3d936740f7b920fec16947f94343a86@localhost> References: <042.a3d936740f7b920fec16947f94343a86@localhost> Message-ID: <051.5a020a1354ee3d3b583a81f1bc7f8da1@localhost> #265: Cabal field stability not useful ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by guest): I don't entirely follow; since it's not being used much, or for any particular purpose, deprecation isn't a bad idea. But I'm not exactly sure what you mean by 'a field for the api versioning scheme'. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sat May 3 08:44:57 2008 From: trac at galois.com (Hackage) Date: Sat May 3 08:39:18 2008 Subject: [Hackage] #265: Cabal field stability not useful In-Reply-To: <042.a3d936740f7b920fec16947f94343a86@localhost> References: <042.a3d936740f7b920fec16947f94343a86@localhost> Message-ID: <051.4f3c6490762fd0f33cd23158f732a080@localhost> #265: Cabal field stability not useful ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Ah, I mean something like the [http://haskell.org/haskellwiki/Package_versioning_policy package versioning policy]. It would be useful for packages to opt-in and declare that they follow the versioning policy. It provides similar information to the stability field but it's more precise and more useful. It also gives us the potential to check that packages that following the versioning policy really are doing so. -- Ticket URL: Hackage Hackage: Cabal and related projects From nominolo at googlemail.com Sat May 3 09:35:23 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sat May 3 09:29:54 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <1CF77D06-B9B3-4582-A6C5-21A1052F01D4@googlemail.com> <1209685777.30059.228.camel@localhost> Message-ID: <09CAC1C8-8897-4728-BBFE-CCC2D4FA53E3@googlemail.com> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080503/108402f5/PGP-0001.bin From apfelmus at quantentunnel.de Sun May 4 06:01:15 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Sun May 4 05:55:50 2008 Subject: Specifying dependencies on Haskell code In-Reply-To: <09CAC1C8-8897-4728-BBFE-CCC2D4FA53E3@googlemail.com> References: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> <1CF77D06-B9B3-4582-A6C5-21A1052F01D4@googlemail.com> <1209685777.30059.228.camel@localhost> <09CAC1C8-8897-4728-BBFE-CCC2D4FA53E3@googlemail.com> Message-ID: Thomas Schilling wrote: > apfelmus wrote: >> >> 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. > > I think we mean the same thing. Yes, albeit with the small difference that in my case, the library user never specifies version ranges, he only specifies the particular libraries he is using: build-depends: foo-0.42.1, bar-2.3.3 Whether other versions of foo and bar can be substituted for these will be determined later, based on information from the library author (f.i. the PVP). The simplest model would be that the library author specifies a transitive relation foo-y > foo-x <=> foo-y can be used in place of foo-x ("subsumes") Most often, this will just follow the PVP, but he could also specify things like foo-0.42 < foo-0.43 and the like. At build time, the system checks whether the user has libraries installed that subsume the build-dependencies. A more sophisticated model would be to associate > with some kind of wrapper function, i.e. something that converts foo-0.42.2 into foo-0.42.1 . Most of the time, this is simply the identity or a function that removes some exports (i.e. a projection) but even more sophisticated legacy support is possible. But of course, if I want to compile something that depends on a very old package, I just download that old package and compile with it, right? > 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. Yes. > 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. I wouldn't necessarily choose the traditional changelog (i.e. diffs) as the concrete data format to specify compatibility information. I mean, that's an algorithmic choice already. > With more information (obtained mostly by tools) we can automate this > process, and, in fact, both approaches can co-exist. I am a bit reluctant concerning tools, in the following sense: either the information is "new" and cannot deduced automatically or it can always be deduced automatically. In the latter case, the human has already specified the information (although maybe implicit and scattered over different source files), hence the tool should be mandatory, i.e. not a tool at all. > 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). Yes. I wouldn't make "virtual packages" a special case, though. In my eyes, packages/modules are just functions data a := b = a := b data Name = String data Value = .. -- represents haskell code type CompiledModule = Set (Name := Value) module foobar :: CompiledModule -> CompiledModule -> CompiledModule and both normal and virtual packages can be represented with the same model here. Regards, apfelmus From trac at galois.com Sun May 4 07:41:31 2008 From: trac at galois.com (Hackage) Date: Sun May 4 07:35:47 2008 Subject: [Hackage] #232: implement extended syntax for package version ranges In-Reply-To: <043.9dc7ddafd560f5be87400ac3e0433964@localhost> References: <043.9dc7ddafd560f5be87400ac3e0433964@localhost> Message-ID: <052.9441a45bca186f43fe4aca083ca41e18@localhost> #232: implement extended syntax for package version ranges ----------------------------+----------------------------------------------- Reporter: duncan | Owner: nominolo Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.6 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Note that if the `foo ~ 1.2.1+` syntax is too confusing we could do with just `foo ~ 1.2.* && >= 1.2.1`. It also allows to depend on a micro release that fixes a bug like `foo ~ 1.2.* && >= 1.2.0.1`. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Sun May 4 12:37:45 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun May 4 12:32:04 2008 Subject: patch applied (cabal): Reverse the order of the args to PackageIndex.insert Message-ID: <20080504163745.GA27532@haskell.galois.com> Sun May 4 06:03:17 PDT 2008 Duncan Coutts * 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-b3c7de9a532b130153e1520e17f7729c5a4c6256.gz From duncan.coutts at worc.ox.ac.uk Sun May 4 12:37:50 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun May 4 12:32:04 2008 Subject: patch applied (cabal): Change dependencyInconsistencies to not take the pseudo top package Message-ID: <20080504163750.GA27556@haskell.galois.com> Sun May 4 06:08:02 PDT 2008 Duncan Coutts * 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-c3f2af9b9f33dab99f79d9b3816797620e958d88.gz From duncan.coutts at worc.ox.ac.uk Sun May 4 12:37:52 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun May 4 12:32:09 2008 Subject: patch applied (cabal): Add PackageIndex.dependencyCycles Message-ID: <20080504163752.GA27573@haskell.galois.com> Sun May 4 06:16:26 PDT 2008 Duncan Coutts * 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-73906b092fb48bd20ff2ed6aea47bea26ec886a5.gz From duncan.coutts at worc.ox.ac.uk Mon May 5 05:14:43 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 5 05:08:56 2008 Subject: patch applied (cabal): Cope better with ghc bug #2201, display a better error message Message-ID: <20080505091443.GA20007@haskell.galois.com> Mon May 5 01:57:46 PDT 2008 Duncan Coutts * 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-30b21f3f434bdf43f0dea4fe3d1baf5c8f33006d.gz From duncan.coutts at worc.ox.ac.uk Mon May 5 05:23:03 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 5 05:17:16 2008 Subject: patch applied (cabal-branches/cabal-1.4): Add an --internal flag to HaddockFlags Message-ID: <20080505092303.GA20320@haskell.galois.com> Thu May 1 07:51:03 PDT 2008 Joachim Breitner * 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/20080501145103-23c07-6467705161f8b10d3fd1e94d50c15b2f5f749aa7.gz From duncan.coutts at worc.ox.ac.uk Mon May 5 05:23:07 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 5 05:17:19 2008 Subject: patch applied (cabal-branches/cabal-1.4): Implement --internal flag Message-ID: <20080505092307.GA20345@haskell.galois.com> Thu May 1 08:24:21 PDT 2008 Joachim Breitner * 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 M ./Distribution/Simple/Haddock.hs -4 +13 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080501152421-23c07-49770b4462ef8c24e3657ea47bda7db4be59e75d.gz From duncan.coutts at worc.ox.ac.uk Mon May 5 05:23:08 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 5 05:17:20 2008 Subject: patch applied (cabal-branches/cabal-1.4): With --executable, --internal just adds --ignore-all-exports Message-ID: <20080505092308.GA20366@haskell.galois.com> Thu May 1 08:25:44 PDT 2008 Joachim Breitner * With --executable, --internal just adds --ignore-all-exports M ./Distribution/Simple/Haddock.hs -1 +6 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080501152544-23c07-e4deafe31ec21b6e8076149277330eca2bcf99c2.gz From duncan.coutts at worc.ox.ac.uk Mon May 5 05:23:10 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 5 05:17:22 2008 Subject: patch applied (cabal-branches/cabal-1.4): Document --internal in Cabal.xml Message-ID: <20080505092310.GA20386@haskell.galois.com> Thu May 1 08:33:56 PDT 2008 Joachim Breitner * Document --internal in Cabal.xml M ./doc/Cabal.xml +9 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080501153356-23c07-b5c9513f0088d5a64fbf95ba6dc8961162f92952.gz From duncan.coutts at worc.ox.ac.uk Mon May 5 05:23:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 5 05:17:23 2008 Subject: patch applied (cabal-branches/cabal-1.4): Revert the change about the --internal flag and a warning about haddock Message-ID: <20080505092312.GA20403@haskell.galois.com> Thu May 1 15:31:31 PDT 2008 Duncan Coutts * 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-branches/cabal-1.4/_darcs/patches/20080501223131-adfee-a06a2a6941538589bbfee6f241df4973ec867bfc.gz From duncan.coutts at worc.ox.ac.uk Mon May 5 05:23:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 5 05:17:26 2008 Subject: patch applied (cabal-branches/cabal-1.4): Reverse the order of the args to PackageIndex.insert Message-ID: <20080505092313.GA20420@haskell.galois.com> Sun May 4 06:03:17 PDT 2008 Duncan Coutts * 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-branches/cabal-1.4/_darcs/patches/20080504130317-adfee-b3c7de9a532b130153e1520e17f7729c5a4c6256.gz From duncan.coutts at worc.ox.ac.uk Mon May 5 05:23:15 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 5 05:17:28 2008 Subject: patch applied (cabal-branches/cabal-1.4): Change dependencyInconsistencies to not take the pseudo top package Message-ID: <20080505092315.GA20437@haskell.galois.com> Sun May 4 06:08:02 PDT 2008 Duncan Coutts * 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-branches/cabal-1.4/_darcs/patches/20080504130802-adfee-c3f2af9b9f33dab99f79d9b3816797620e958d88.gz From duncan.coutts at worc.ox.ac.uk Mon May 5 05:23:16 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 5 05:17:28 2008 Subject: patch applied (cabal-branches/cabal-1.4): Add PackageIndex.dependencyCycles Message-ID: <20080505092316.GA20456@haskell.galois.com> Sun May 4 06:16:26 PDT 2008 Duncan Coutts * 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-branches/cabal-1.4/_darcs/patches/20080504131626-adfee-73906b092fb48bd20ff2ed6aea47bea26ec886a5.gz From duncan.coutts at worc.ox.ac.uk Mon May 5 05:23:18 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 5 05:17:30 2008 Subject: patch applied (cabal-branches/cabal-1.4): Cope better with ghc bug #2201, display a better error message Message-ID: <20080505092318.GA20474@haskell.galois.com> Mon May 5 01:57:46 PDT 2008 Duncan Coutts * 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-branches/cabal-1.4/_darcs/patches/20080505085746-adfee-30b21f3f434bdf43f0dea4fe3d1baf5c8f33006d.gz From duncan.coutts at worc.ox.ac.uk Mon May 5 05:25:03 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 5 05:19:17 2008 Subject: patch applied (cabal-install): Update for flipped order of args for PackageIndex.insert Message-ID: <20080505092503.GA20656@haskell.galois.com> Sun May 4 12:37:22 PDT 2008 Duncan Coutts * Update for flipped order of args for PackageIndex.insert M ./Hackage/Install.hs -1 +1 M ./Hackage/InstallPlan.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080504193722-adfee-0c1fcf78f266252daf28e20c9deb49a1ea5f78f9.gz From duncan at haskell.org Mon May 5 05:36:41 2008 From: duncan at haskell.org (Duncan Coutts) Date: Mon May 5 05:29:55 2008 Subject: darcs patch: Add new utils, duplicates, duplicatesBy ... (and 4 more) Message-ID: <20080505092953.D3FA232412D@www.haskell.org> All, If you want to play with the new dependency resolver stuff then here is a bunch of patches. Dependency resolvers are now expected to produce a valid InstallPlan. There is new error checking code to tell you all the ways in which the InstallPlan your dep resolver produced, is invalid. The current dep resolver can sometimes produce valid install plans but can easily be persuaded into making invalid ones, especially if you have many broken packages installed. So there's still some work to be done to make the dep resolvers more pluggable and to try to patch up the current dep resolver a bit. Duncan Sun May 4 20:45:30 BST 2008 Duncan Coutts * Add new utils, duplicates, duplicatesBy and mergeBy Sun May 4 21:17:42 BST 2008 Duncan Coutts * Use the mergeBy from the Utils module Sun May 4 21:18:57 BST 2008 Duncan Coutts * Improve InstallPlan error checking and reporting Instead of just reporting that a plan is invalid, produce a detailed list of reasons why it is invalid. This should be useful for people debugging dependency resolvers. Also rename the complete property to closed, since the property is about the set being closed under the dependency relation. Also re-use the PackageIndex functions for checking the validity conditions rather than re-implementing the checks locally. Mon May 5 10:05:13 BST 2008 Duncan Coutts * Packages are only invalid if they have more than zero problems. Mon May 5 10:17:43 BST 2008 Duncan Coutts * Switch from DepGraph to InstallPlan The dependency resolver has had to be extended in a slightly hacky way to gather the extra information needed by an install plan. In particular it requires the flags to use to configure each package, the actual versions of dependencies to use and all of the installed packages and their closure of dependencies. However the current resolver is fairly naive and so can be easily persuaded into producing an invalid install plan, in which case you'll get a detailed list of reasons as to why it is invalid. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 41503 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080505/03415543/attachment-0001.bin From benjovi at gmx.net Tue May 6 04:30:33 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Tue May 6 04:29:16 2008 Subject: cabal-install uninstall ? Message-ID: Hello, I appreciate ongoing work with cabal-install. I've tried the latest darcs version on a clean fresh ghc, and it worked fine. I wonder however, if there is any support (planned) for removing outdated packages. For example, when updating bytestring, I ended up with both xhtml-3000.0.2.1 and xhtml-3000.0.2.2 installed. Is there a something like a receipt, listing the files belonging to the installation of a package ? If there were such a thing (like copy --verbose, but machine readable), uninstalling a list of outdated packages would at least be possible. I wouldn't want cabal to remove outdated packages automatically, but some support for listing and removing them seems quite important to me. Oh, and it would be nice if config fields like 'global-prefix' are mentioned in the README. In the long term, in which way should cabal-install interact with package management tools like macports ? Is it supposed to be a replacement, an alternative or a complement ? I thought about writing something similar as cabal-rpm for macports, but it seems better to have cabal-install handle dependency resolution and installation. Injecting a package into the pm's database after installing is imho the nicest solution. Does this make sense ? Thanks, Benedikt From duncan.coutts at worc.ox.ac.uk Tue May 6 05:36:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 05:29:24 2008 Subject: version tags Message-ID: <1210066572.30059.313.camel@localhost> Hmm, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa-0.92-ghc-68-build-fix http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa-0.92 Version [0,92] [] == Version [0,92] ["ghc", "68", "build", "fix"] = False I'm sure this is going to break something, though I'm not sure exactly what yet. We should figure something out. Duncan From duncan.coutts at worc.ox.ac.uk Tue May 6 05:56:17 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 05:49:22 2008 Subject: cabal-install uninstall ? In-Reply-To: References: Message-ID: <1210067777.30059.323.camel@localhost> On Tue, 2008-05-06 at 10:30 +0200, Benedikt Huber wrote: > Hello, > > I appreciate ongoing work with cabal-install. I've tried the latest > darcs version on a clean fresh ghc, and it worked fine. Great. > I wonder however, if there is any support (planned) for removing > outdated packages. For example, when updating bytestring, I ended up > with both xhtml-3000.0.2.1 and xhtml-3000.0.2.2 installed. > > Is there a something like a receipt, listing the files belonging to the > installation of a package ? If there were such a thing (like copy > --verbose, but machine readable), uninstalling a list of outdated > packages would at least be possible. > I wouldn't want cabal to remove outdated packages automatically, but > some support for listing and removing them seems quite important to me. http://hackage.haskell.org/trac/hackage/ticket/234 So as you say, the way to do this would be to generate a list of files that will be installed. This can be used to later uninstall. If you want to work on this feature I can provide some advice on how to implement it. It'll need a bit of work to restructure the install code so that it actually produces a list of things to install, rather than just installing them. > Oh, and it would be nice if config fields like 'global-prefix' are > mentioned in the README. And indeed in comments in the config file itself. > In the long term, in which way should cabal-install interact with > package management tools like macports ? Is it supposed to be a > replacement, an alternative or a complement ? It's not 100% clear. It is certainly not a replacement and it cannot be used to install other kinds of packages but it's also not realistic to expect all hackage packages to be supplied by every distro so we really have to aim for some kind of co-existance. cabal-install is also primarily a per-user package manager, not requiring any privileges to build and install packages. Most other package managers are global. > I thought about writing something similar as cabal-rpm for macports, but > it seems better to have cabal-install handle dependency resolution and > installation. Injecting a package into the pm's database after > installing is imho the nicest solution. Does this make sense ? What the best integration point is will depend on the package manager and the features you want. If you want to be able to use the package manager's dependency tracking then it has to go in at a higher level than just recording what the installed files are. Duncan From duncan.coutts at worc.ox.ac.uk Tue May 6 06:30:57 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 06:25:07 2008 Subject: patch applied (cabal): Remove a test for the specific kind of exception for nhc98 compatibility Message-ID: <20080506103057.GA19751@haskell.galois.com> Tue May 6 03:28:04 PDT 2008 Duncan Coutts * Remove a test for the specific kind of exception for nhc98 compatibility This was the check for ghc-pkg failing. We cannot check for the exception being an ExitException since that assumes ghc's representation of the Exception type, whereas nhc98 defines: type Exception = IOError M ./Distribution/Simple/GHC.hs -6 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080506102804-adfee-4c87c7217f11884c5bd7dc28f026a83ccd84538e.gz From marco-oweber at gmx.de Tue May 6 13:08:26 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Tue May 6 13:02:35 2008 Subject: cabal-install uninstall ? In-Reply-To: References: Message-ID: <20080506170825.GC15613@gmx.de> Hi Benedikt. Having a ./setup install-update-remove-outdated seems to be fine.. However how should cabal know which package versions are needed by your applications? Eg you might be working on a project requiring xhtml-3000.0.2.1 (A) and beeing not compatible with xhtml-3001 ? So this should only be done on major version numbers for packages using the x.x.x.x versioning scheme. There is another issue: If you have another package isntalled having been compiled with the old xhtml package it would be fatal to remove it because that library depends on the old version I think (not totally sure.. at least having none breaks ..) ? Has someone tried this? All package-deps are build time deps AFAIK (?) If you want this behaviour you can try nix. you can install a ghc wrapper with a set of libs. Updating a package updates all of them. However there is a drawback: nix is a whole distribution system.. You'll get glibc etc again as well. It's my tool of choice getting rid of all this update / when to delete what issues by using kind of garbage collector applied to your disk store content. Writing a tool removing all old versions isn't hard at all because all package databases are just written using show and there is a read instance. Using ghc-pkg list and filtering all lines ending with ':' (cabal is doing this) should give you a list of all package databases. Read them and check for them by yourself It looks like this. (packagedb :: [InstalledPackageInfo] ) <- fmap read $ myReadFile Creating a map sorted by names without versions and then listing/ removing old duplicates should be trivial. I've never really worked on a mac.. So maybe this all doesn't apply to you. Sincerly Marc Weber From marco-oweber at gmx.de Tue May 6 13:24:25 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Tue May 6 13:18:34 2008 Subject: A (in)sane idea about (never) breaking Setup.(l)hs files again Message-ID: <20080506172425.GD15613@gmx.de> module Main where import Distribution.Simple72 main = mainWithHooks ( .... ) Could be one way to achieve this goal in most simpler API changes (up to rewriting the whole core using more monads as all information is pased) How could it work? The Cabal distribution ships with src/Distribution/Simple1.hs: import Distribution.Simple2 import Types1 import Types2 -- wrapper for the new Simple2 api exporting API1 [..] src/Distribution/Simple2.hs: import Distribution.Simple3 [..] I guess you get the idea. This way API v1 uses API v2 using API v3 .. using API vlatest. There is another case: What happens if the Setup.hs fits a newer cabal version (2) but you have only (1) installed? You could get an api wrapper mapping API v2 back to API1 you have. And the cool thing: Adding this wrapper could be automated because reading the Distribution.SimpleX versions is simple.. Propably the best way handling this case is: Update your Cabal version anyway :) It's a nice documentation about how to upgrade your Setup files as well.. because looking at the "dummy" files only calling the other API versions should give you all you need. I'm not sure about how everyone would like having Distribution/Simple{1,2,3,4,5,6,7,8,9,...200}.hs files But thinking about how many cabal using people could benefit from this easy to accomplish up and downgrading it might be worth it. Some small changes (removing the Bool arg in runTests) and the flagVerbose change would be really trivial then without having to read lots of Cabal code I think Cabal devs know best how often this could have helped people ? It would make the life of all package mantainers a lot easier.. and of those devs having SetupX{1,2,3}.hs flying around. You can't forget about all trouble.. just about some incompatibilies. Any thoughts? Marc Weber From duncan.coutts at worc.ox.ac.uk Tue May 6 15:38:27 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 15:32:35 2008 Subject: patch applied (cabal): Add PackageIndex.delete Message-ID: <20080506193827.GA31176@haskell.galois.com> Tue May 6 06:16:03 PDT 2008 Duncan Coutts * Add PackageIndex.delete We occasionally need to remove packages from an index eg to restrict the choices of a dependency resolver. M ./Distribution/Simple/PackageIndex.hs -1 +14 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080506131603-adfee-ea63571841f7c16a7b4ecf330dcfcaf1f62c9999.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:21:58 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:16:07 2008 Subject: patch applied (cabal): Improve style and performance of PackageIndex.dependencyClosure Message-ID: <20080507002158.GA10511@haskell.galois.com> Tue May 6 16:44:47 PDT 2008 Duncan Coutts * Improve style and performance of PackageIndex.dependencyClosure Keep the completed set as another PackageIndex rather than a list. We want to return an index at the end anyway and in the mean time we want to do lots of lookups to see if we've visited previously. M ./Distribution/Simple/PackageIndex.hs -12 +10 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080506234447-adfee-60242561c4f80aca290c1faa3b28819f681de819.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:21:57 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:16:08 2008 Subject: patch applied (cabal): Add PackageIndex.dependencyGraph that builds a Graph Message-ID: <20080507002157.GA10485@haskell.galois.com> Tue May 6 16:43:26 PDT 2008 Duncan Coutts * Add PackageIndex.dependencyGraph that builds a Graph Useful for some more tricky queries. M ./Distribution/Simple/PackageIndex.hs +34 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080506234326-adfee-f3e9bb77388e5571e42bb3d9d22349b76f56410e.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:22:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:16:08 2008 Subject: patch applied (cabal): Add PackageIndex.reverseDependencyClosure Message-ID: <20080507002200.GA10528@haskell.galois.com> Tue May 6 16:49:02 PDT 2008 Duncan Coutts * Add PackageIndex.reverseDependencyClosure It's similar to dependencyClosure but looks at reverse dependencies. For example it's useful to find all packages that depend on broken packages and are thus themselves broken. M ./Distribution/Simple/PackageIndex.hs -1 +22 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080506234902-adfee-09deee714d59d55e06e34f8b7d4abab08d61cc7e.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:10 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:17 2008 Subject: patch applied (cabal-branches/cabal-1.4): Remove a test for the specific kind of exception for nhc98 compatibility Message-ID: <20080507003410.GA11365@haskell.galois.com> Tue May 6 03:28:04 PDT 2008 Duncan Coutts * Remove a test for the specific kind of exception for nhc98 compatibility This was the check for ghc-pkg failing. We cannot check for the exception being an ExitException since that assumes ghc's representation of the Exception type, whereas nhc98 defines: type Exception = IOError M ./Distribution/Simple/GHC.hs -6 +2 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080506102804-adfee-4c87c7217f11884c5bd7dc28f026a83ccd84538e.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:11 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:18 2008 Subject: patch applied (cabal-branches/cabal-1.4): Add PackageIndex.delete Message-ID: <20080507003411.GA11391@haskell.galois.com> Tue May 6 06:16:03 PDT 2008 Duncan Coutts * Add PackageIndex.delete We occasionally need to remove packages from an index eg to restrict the choices of a dependency resolver. M ./Distribution/Simple/PackageIndex.hs -1 +14 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080506131603-adfee-ea63571841f7c16a7b4ecf330dcfcaf1f62c9999.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:21 2008 Subject: patch applied (cabal-branches/cabal-1.4): Add PackageIndex.dependencyGraph that builds a Graph Message-ID: <20080507003413.GA11408@haskell.galois.com> Tue May 6 16:43:26 PDT 2008 Duncan Coutts * Add PackageIndex.dependencyGraph that builds a Graph Useful for some more tricky queries. M ./Distribution/Simple/PackageIndex.hs +34 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080506234326-adfee-f3e9bb77388e5571e42bb3d9d22349b76f56410e.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:14 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:23 2008 Subject: patch applied (cabal-branches/cabal-1.4): Improve style and performance of PackageIndex.dependencyClosure Message-ID: <20080507003414.GA11425@haskell.galois.com> Tue May 6 16:44:47 PDT 2008 Duncan Coutts * Improve style and performance of PackageIndex.dependencyClosure Keep the completed set as another PackageIndex rather than a list. We want to return an index at the end anyway and in the mean time we want to do lots of lookups to see if we've visited previously. M ./Distribution/Simple/PackageIndex.hs -12 +10 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080506234447-adfee-60242561c4f80aca290c1faa3b28819f681de819.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:16 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:24 2008 Subject: patch applied (cabal-branches/cabal-1.4): Add PackageIndex.reverseDependencyClosure Message-ID: <20080507003416.GA11444@haskell.galois.com> Tue May 6 16:49:02 PDT 2008 Duncan Coutts * Add PackageIndex.reverseDependencyClosure It's similar to dependencyClosure but looks at reverse dependencies. For example it's useful to find all packages that depend on broken packages and are thus themselves broken. M ./Distribution/Simple/PackageIndex.hs -1 +22 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080506234902-adfee-09deee714d59d55e06e34f8b7d4abab08d61cc7e.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:35 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:43 2008 Subject: patch applied (cabal-install): Add new utils, duplicates, duplicatesBy and mergeBy Message-ID: <20080507003435.GA11500@haskell.galois.com> Sun May 4 12:45:30 PDT 2008 Duncan Coutts * Add new utils, duplicates, duplicatesBy and mergeBy M ./Hackage/Utils.hs +31 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080504194530-adfee-af9508a978ca6bb0ba7c70914d3474ab4e08226f.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:37 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:44 2008 Subject: patch applied (cabal-install): Use the mergeBy from the Utils module Message-ID: <20080507003437.GA11520@haskell.galois.com> Sun May 4 13:17:42 PDT 2008 Duncan Coutts * Use the mergeBy from the Utils module M ./Hackage/List.hs -17 +7 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080504201742-adfee-9ef005e6e657d40807a8ada03505ac37baca8fa7.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:38 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:47 2008 Subject: patch applied (cabal-install): Improve InstallPlan error checking and reporting Message-ID: <20080507003438.GA11537@haskell.galois.com> Sun May 4 13:18:57 PDT 2008 Duncan Coutts * Improve InstallPlan error checking and reporting Instead of just reporting that a plan is invalid, produce a detailed list of reasons why it is invalid. This should be useful for people debugging dependency resolvers. Also rename the complete property to closed, since the property is about the set being closed under the dependency relation. Also re-use the PackageIndex functions for checking the validity conditions rather than re-implementing the checks locally. M ./Hackage/InstallPlan.hs -105 +234 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080504201857-adfee-87a10bfc726b382c6bec4fbc58ef5a9770b51e58.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:40 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:49 2008 Subject: patch applied (cabal-install): Packages are only invalid if they have more than zero problems. Message-ID: <20080507003440.GA11554@haskell.galois.com> Mon May 5 02:05:13 PDT 2008 Duncan Coutts * Packages are only invalid if they have more than zero problems. M ./Hackage/InstallPlan.hs -2 +4 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080505090513-adfee-28c25b76fed9c0b3f4db73e2066d5056ce1ec2db.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:41 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:49 2008 Subject: patch applied (cabal-install): Switch from DepGraph to InstallPlan Message-ID: <20080507003441.GA11574@haskell.galois.com> Mon May 5 02:17:43 PDT 2008 Duncan Coutts * Switch from DepGraph to InstallPlan The dependency resolver has had to be extended in a slightly hacky way to gather the extra information needed by an install plan. In particular it requires the flags to use to configure each package, the actual versions of dependencies to use and all of the installed packages and their closure of dependencies. However the current resolver is fairly naive and so can be easily persuaded into producing an invalid install plan, in which case you'll get a detailed list of reasons as to why it is invalid. R ./Hackage/DepGraph.hs M ./Hackage/Dependency.hs -28 +84 M ./Hackage/Fetch.hs -4 +7 M ./Hackage/Install.hs -43 +35 M ./cabal-install.cabal -1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080505091743-adfee-c005075e895dd07eb7d174c7ede9d7d9179db6ad.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:43 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:50 2008 Subject: patch applied (cabal-install): Add more info and debug messages at key parts of the install process Message-ID: <20080507003443.GA11591@haskell.galois.com> Tue May 6 06:30:22 PDT 2008 Duncan Coutts * Add more info and debug messages at key parts of the install process If we're in verbose mode then always print what we're going to install, not just when the user specifies --dry-run. M ./Hackage/Install.hs -2 +6 M ./Hackage/SetupWrapper.hs -5 +10 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080506133022-adfee-97d4c40f0bc1c568e709d30dc50fd88a7e152ba5.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:44 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:51 2008 Subject: patch applied (cabal-install): Hide the installed instance when installing the local package. Message-ID: <20080507003444.GA11608@haskell.galois.com> Tue May 6 06:32:36 PDT 2008 Duncan Coutts * Hide the installed instance when installing the local package. Otherwise the dependency resolver may decide to pick the installed instance of the package but we really do want to install the local version. So to remove that choice from the dep resolver we just delete it from the installed package index. M ./Hackage/Install.hs -3 +5 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080506133236-adfee-72ba13b38c8300483a9eadf3d209e821e2129125.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:46 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:55 2008 Subject: patch applied (cabal-install): Minor improvements to InstallPlan documentation and error reporting Message-ID: <20080507003446.GA11631@haskell.galois.com> Tue May 6 16:59:05 PDT 2008 Duncan Coutts * Minor improvements to InstallPlan documentation and error reporting M ./Hackage/InstallPlan.hs -5 +16 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080506235905-adfee-004415ee1f8051bf5d7508ac72f82071036a1066.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:47 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:55 2008 Subject: patch applied (cabal-install): Check that InstallPlan dependencies respect a state relation Message-ID: <20080507003447.GA11648@haskell.galois.com> Tue May 6 17:02:09 PDT 2008 Duncan Coutts * Check that InstallPlan dependencies respect a state relation For example it's not allowed for installed packages to depend on configured packages. M ./Hackage/InstallPlan.hs +38 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080507000209-adfee-98a91b7a7c69c63a5e2721af076f6d7c8dfbfa5c.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:28:57 2008 Subject: patch applied (cabal-install): Add a dependency graph to the InstallPlan Message-ID: <20080507003448.GA11670@haskell.galois.com> Tue May 6 17:06:26 PDT 2008 Duncan Coutts * Add a dependency graph to the InstallPlan Uses Data.Graph and annoyingly we also need to keep functions around for mapping between Graph.Vertex <-> PackageIdentifier M ./Hackage/InstallPlan.hs -4 +24 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080507000626-adfee-7bcffddcef60fbc53271cdf26eca110bf358f556.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:50 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:29:00 2008 Subject: patch applied (cabal-install): Add lookupConfiguredPackage helper function to InstallPlan Message-ID: <20080507003450.GA11687@haskell.galois.com> Tue May 6 17:10:06 PDT 2008 Duncan Coutts * Add lookupConfiguredPackage helper function to InstallPlan Simplifies implementation of completed and failed M ./Hackage/InstallPlan.hs -4 +13 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080507001006-adfee-2aff7725eaf0e06c489eceaadf93b92ab6392d35.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:51 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:29:01 2008 Subject: patch applied (cabal-install): Reimplement InstallPlan.failed as it was completely wrong Message-ID: <20080507003451.GA11709@haskell.galois.com> Tue May 6 17:13:02 PDT 2008 Duncan Coutts * Reimplement InstallPlan.failed as it was completely wrong It was finding all the dependencies of the failed package and marking them as failed. But of course what we have to do is find all the packages that depend on the failed package (the reverse dependencies) and mark them as failed. We use the reverse dependency Graph that we saved in the InstallPlan. M ./Hackage/InstallPlan.hs -19 +16 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080507001302-adfee-d4c784f456875128da9d7dec012dc6838644aa13.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:53 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:29:02 2008 Subject: patch applied (cabal-install): Add an info message when resolving dependencies Message-ID: <20080507003453.GA11726@haskell.galois.com> Tue May 6 17:18:51 PDT 2008 Duncan Coutts * Add an info message when resolving dependencies It can take a while, especially with debug checks turned on. M ./Hackage/Install.hs +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080507001851-adfee-451e3470febbdc80a2f76ab836631be15e293c81.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:34:55 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:29:03 2008 Subject: patch applied (cabal-install): Hide broken installed packages when resolving dependencies Message-ID: <20080507003454.GA11746@haskell.galois.com> Tue May 6 17:21:03 PDT 2008 Duncan Coutts * Hide broken installed packages when resolving dependencies Stops us from choosing them which would always end up with an invalid installation plan. M ./Hackage/Dependency.hs -3 +15 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080507002103-adfee-fe6a16e1b86696c96cbff99ee3c103ac5348f786.gz From duncan.coutts at worc.ox.ac.uk Tue May 6 20:47:21 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 20:40:22 2008 Subject: cabal-install now very picky about install planning Message-ID: <1210121241.30059.382.camel@localhost> Hi all, If you're following the progress of cabal-install this is a heads up. I've switched it over to using this new InstallPlan stuff. So the dependency resolver is now expected to produce a valid install plan. The conditions for validity are quite strict and the current weedy dependency resolver is often not able to make a valid install plan. It is particularly bad with dependencies on inconsistent versions of packages, especially if the already installed packages have such inconsistencies. So watch out for these and report the most common ones and we can think about how to improve the resolver. It does produce fairly detailed error messages describing the problems with the install plan. There's a bit more work to do to make the dep resolver pluggable. I suspect it's not working with hugs at the moment again (producing valid install plans when you've no idea what's installed is more than a little difficult). Duncan From trac at galois.com Wed May 7 18:15:32 2008 From: trac at galois.com (Hackage) Date: Wed May 7 18:09:38 2008 Subject: [Hackage] #274: Add a 'build from sdist tarball' feature Message-ID: <042.0a2588df1d8663c0de389645c595b83e@localhost> #274: Add a 'build from sdist tarball' feature ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- I've often seen Darcs repos where the sdist tarball was incomplete, or where a person had a tarball which was incomplete. I think this is because most people just never use the tarball; if they do ever use it, it's because it's what was downloaded from Hackage. The reason is that doing so is much more complex than 'configure; build; install': you need to configure, create an sdist tarball, cd into dist/; do a tar -xvf or whatever of the correct tarball; cd into *that* - and then you can configure/build/install. Assuming it is a working tarball. Now, of course you can automate it. After the first dozen times, I wrote myself a shellscript to do all that for me: function build_sdist { clean_configure && sdist && cd dist/ && untar *.tar.gz && cd `ls -t ./ | grep "/" | head -n 1` && clean_configure && build && hinstall; haddock && hinstall; } (This is pretty long and imperfect, but it would be even longer if all the other aliases and function definitions were included; I think they're pretty straightforwardly named though, so I haven't included them.) It seems to me that this would be, at the very least, a useful adjunct to cabal check - if it makes sense to see whether various fields are filled out sanely, surely it makes sense to see whether needed files are included/listed? It might be even better to make the normal 'runhaskell Setup build' do it from sdist, but this is harder to code (besides the forgoing, you'd need to copy in the configuration from the top-level, from when the user ran 'runhaskell Setup configure' and added whatever options) and possibly more confusing ("But Foo.hs *is* there, right there in src/! Why can't Cabal find it?"). So I'd be satisfied to do something like 'cabal checkdist'. -- gwern -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Thu May 8 17:45:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 8 17:37:49 2008 Subject: version tags In-Reply-To: <1210066572.30059.313.camel@localhost> References: <1210066572.30059.313.camel@localhost> Message-ID: <1210283106.30059.424.camel@localhost> On Tue, 2008-05-06 at 10:36 +0100, Duncan Coutts wrote: > Hmm, > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa-0.92-ghc-68-build-fix > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa-0.92 > > Version [0,92] [] > == Version [0,92] ["ghc", "68", "build", "fix"] > = False > > > I'm sure this is going to break something, though I'm not sure exactly > what yet. We should figure something out. I suggest that tags should be kept as far as possible but not considered for equality or ordering. Unfortunately Version is defined in base in Data.Version so we will have to submit a library proposal to change the Eq instance. Does this seem like a good idea? What is/was the rationale for tags in the first place? Duncan From trac at galois.com Thu May 8 17:52:08 2008 From: trac at galois.com (Hackage) Date: Thu May 8 17:46:08 2008 Subject: [Hackage] #275: On each package page, give the name of the corresponding debian package Message-ID: <042.b836d8a6d74286e6b93ed2956208753a@localhost> #275: On each package page, give the name of the corresponding debian package --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: minor | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | --------------------------------+------------------------------------------- This is a feature request. I don't know enough to know if this is a good idea, maybe there's a better way of tracking down which debian package to get for a given hackage package. Maybe you could also give corresponding package names for other operating systems. All I know is that I wanted parsec, it didn't come with ubuntu ghc, and I couldn't tell how to get it without asking on #haskell. This could have been resolved by a sentence on the hackageDB page for parsec. -- Ticket URL: Hackage Hackage: Cabal and related projects From ijones at syntaxpolice.org Thu May 8 18:39:09 2008 From: ijones at syntaxpolice.org (Isaac Potoczny-Jones) Date: Thu May 8 18:33:12 2008 Subject: version tags In-Reply-To: <1210283106.30059.424.camel@localhost> References: <1210066572.30059.313.camel@localhost> <1210283106.30059.424.camel@localhost> Message-ID: <4823810D.1040900@syntaxpolice.org> Duncan Coutts wrote: (snip) > Does this seem like a good idea? What is/was the rationale for tags in > the first place? Yes, if I recall, Tags were not originally supposed to affect the ordering of versions, but meant only for human consumption. Whether changing that now is a good idea or not, it's hard to say. How many packages in Hackage have any tags, for instance? peace, isaac From trac at galois.com Thu May 8 18:39:37 2008 From: trac at galois.com (Hackage) Date: Thu May 8 18:33:37 2008 Subject: [Hackage] #275: On each package page, give the name of the corresponding debian package In-Reply-To: <042.b836d8a6d74286e6b93ed2956208753a@localhost> References: <042.b836d8a6d74286e6b93ed2956208753a@localhost> Message-ID: <051.962891e3e2c92ee60993acdaaa71ff30@localhost> #275: On each package page, give the name of the corresponding debian package --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: minor | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux --------------------------------+------------------------------------------- Changes (by ross): * type: defect => enhancement -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Thu May 8 19:07:42 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 8 19:00:25 2008 Subject: version tags In-Reply-To: <4823810D.1040900@syntaxpolice.org> References: <1210066572.30059.313.camel@localhost> <1210283106.30059.424.camel@localhost> <4823810D.1040900@syntaxpolice.org> Message-ID: <1210288062.5824.3.camel@localhost> On Thu, 2008-05-08 at 15:39 -0700, Isaac Potoczny-Jones wrote: > Duncan Coutts wrote: > (snip) > > Does this seem like a good idea? What is/was the rationale for tags in > > the first place? > > Yes, if I recall, Tags were not originally supposed to affect the > ordering of versions, And actually they don't affect the ordering but they do affect equality. Yes it's inconsistent. If we look in the base library in Data.Version we find: instance Eq Version where v1 == v2 = versionBranch v1 == versionBranch v2 && sort (versionTags v1) == sort (versionTags v2) -- tags may be in any order instance Ord Version where v1 `compare` v2 = versionBranch v1 `compare` versionBranch v2 This is clearly wrong. We would expect that: a == b <=> compare a b == EQ but that does not hold here. > but meant only for human consumption. Whether > changing that now is a good idea or not, it's hard to say. How many > packages in Hackage have any tags, for instance? One. It was uploaded the other day which is why I just noticed that it's a problem. Duncan From duncan.coutts at worc.ox.ac.uk Thu May 8 19:27:07 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 8 19:21:08 2008 Subject: patch applied (cabal-install): Move ConfiguredPackage type into Types module Message-ID: <20080508232707.GA9245@haskell.galois.com> Wed May 7 08:57:25 PDT 2008 Duncan Coutts * Move ConfiguredPackage type into Types module It's not actually specific to the InstallPlan. M ./Hackage/Install.hs -1 +1 M ./Hackage/InstallPlan.hs -20 +2 M ./Hackage/Types.hs -1 +21 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080507155725-adfee-744075810cf343152b459d6465cf5401921c38e3.gz From duncan.coutts at worc.ox.ac.uk Thu May 8 19:27:08 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 8 19:21:09 2008 Subject: patch applied (cabal-install): Refactor installLocalPackage and installRepoPackages Message-ID: <20080508232708.GA9269@haskell.galois.com> Wed May 7 11:01:08 PDT 2008 Duncan Coutts * Refactor installLocalPackage and installRepoPackages They share most code so pull the first and last bits out into the top level install function. They now need 2 and 3 fewer params respectively, which is a good sign. Rename them because they're generating plans now rather than doing the installation directly. M ./Hackage/Install.hs -59 +48 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080507180108-adfee-63c047da8b3782ae8b14c0360d134be3accb8c78.gz From duncan.coutts at worc.ox.ac.uk Thu May 8 19:27:10 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 8 19:21:11 2008 Subject: patch applied (cabal-install): Tidy planLocalPackage and planRepoPackages a bit more Message-ID: <20080508232710.GA9287@haskell.galois.com> Wed May 7 11:17:33 PDT 2008 Duncan Coutts * Tidy planLocalPackage and planRepoPackages a bit more M ./Hackage/Install.hs -47 +38 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080507181733-adfee-dd6b6efbc9690d1218d28bed513adf21826d966d.gz From duncan.coutts at worc.ox.ac.uk Thu May 8 19:27:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 8 19:21:13 2008 Subject: patch applied (cabal-install): executeInstallPlan now takes an installer instead of calling installPkg Message-ID: <20080508232711.GA9305@haskell.galois.com> Wed May 7 11:21:58 PDT 2008 Duncan Coutts * executeInstallPlan now takes an installer instead of calling installPkg Four of the executeInstallPlan param were just passed through directly to installPkg so this decouples them a bit. M ./Hackage/Install.hs -24 +19 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080507182158-adfee-de240e450b0f4e39db46cfb97bc4770fbfd78bd5.gz From duncan.coutts at worc.ox.ac.uk Thu May 8 19:27:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 8 19:21:14 2008 Subject: patch applied (cabal-install): Restructure the package installing code Message-ID: <20080508232713.GA9324@haskell.galois.com> Thu May 8 02:26:49 PDT 2008 Duncan Coutts * Restructure the package installing code Previously each layer called the next layer down and therefore the top layer had to take all of the params that the bottom layer needed even though they were mostly or wholly unmodified on the way down. Now each layer takes the next layer as a parameter so we do not need to take the params that are not used directly by the current layer. The overall stack is then built by applying each layer to the next. M ./Hackage/Install.hs -59 +42 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080508092649-adfee-0a060fb2225c3e13cfca26ea3fd693bb6a144253.gz From ijones at syntaxpolice.org Thu May 8 19:54:26 2008 From: ijones at syntaxpolice.org (Isaac Potoczny-Jones) Date: Thu May 8 19:48:33 2008 Subject: version tags In-Reply-To: <1210288062.5824.3.camel@localhost> References: <1210066572.30059.313.camel@localhost> <1210283106.30059.424.camel@localhost> <4823810D.1040900@syntaxpolice.org> <1210288062.5824.3.camel@localhost> Message-ID: <482392B2.8030200@syntaxpolice.org> Duncan Coutts wrote: > On Thu, 2008-05-08 at 15:39 -0700, Isaac Potoczny-Jones wrote: >> Duncan Coutts wrote: >> (snip) >>> Does this seem like a good idea? What is/was the rationale for tags in >>> the first place? >> Yes, if I recall, Tags were not originally supposed to affect the >> ordering of versions, > > And actually they don't affect the ordering but they do affect equality. > Yes it's inconsistent. > > If we look in the base library in Data.Version we find: > > instance Eq Version where > v1 == v2 = versionBranch v1 == versionBranch v2 > && sort (versionTags v1) == sort (versionTags v2) > -- tags may be in any order > > instance Ord Version where > v1 `compare` v2 = versionBranch v1 `compare` versionBranch v2 > > This is clearly wrong. We would expect that: > a == b > <=> compare a b == EQ > but that does not hold here. Ewwwwwwwwwww. >> but meant only for human consumption. Whether >> changing that now is a good idea or not, it's hard to say. How many >> packages in Hackage have any tags, for instance? > > One. It was uploaded the other day which is why I just noticed that it's > a problem. Sounds like it's a good time to fix it now. I'm surprised that only one package uses tags, though. Maybe add something to the package lint during upload too? peace, isaac From trac at galois.com Fri May 9 01:00:40 2008 From: trac at galois.com (Hackage) Date: Fri May 9 00:54:41 2008 Subject: [Hackage] #276: Add support for convenience libraries Message-ID: <039.485a49f8e972177d4013fdb0eb3f6108@localhost> #276: Add support for convenience libraries ----------------------------+----------------------------------------------- Reporter: rl | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- I'd like to have a package with several binaries which all use a convenience library included in that same package. The convenience library should NOT be installed. For this to work, Cabal needs two things. Firstly, it must allow dependencies within a package such that I could describe the library and have the binaries depend on it. Secondly, it should have an "installable" flag, similar to "buildable". A thing that's not installable would be built but not installed. The same mechanism could be used for package-internal tools. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Fri May 9 05:12:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 9 05:04:47 2008 Subject: version tags In-Reply-To: <482392B2.8030200@syntaxpolice.org> References: <1210066572.30059.313.camel@localhost> <1210283106.30059.424.camel@localhost> <4823810D.1040900@syntaxpolice.org> <1210288062.5824.3.camel@localhost> <482392B2.8030200@syntaxpolice.org> Message-ID: <1210324326.5824.10.camel@localhost> On Thu, 2008-05-08 at 16:54 -0700, Isaac Potoczny-Jones wrote: > Duncan Coutts wrote: > > And actually they don't affect the ordering but they do affect equality. > > Yes it's inconsistent. > > > > If we look in the base library in Data.Version we find: > > > > instance Eq Version where > > v1 == v2 = versionBranch v1 == versionBranch v2 > > && sort (versionTags v1) == sort (versionTags v2) > > -- tags may be in any order > > > > instance Ord Version where > > v1 `compare` v2 = versionBranch v1 `compare` versionBranch v2 > > > > This is clearly wrong. We would expect that: > > a == b > > <=> compare a b == EQ > > but that does not hold here. > > Ewwwwwwwwwww. Yeah quite :-) > Sounds like it's a good time to fix it now. I'm surprised that only one > package uses tags, though. It's clear we should drop the check on the tags from the == test but I'm not sure if we should also change the showVersion or parseVersion functions. I'm planning on changing the equivalent of showVersion in Cabal to not display the tags. > Maybe add something to the package lint during upload too? I've attached a patch to do that and I'm cc'ing Ross so he can decide if he agrees or not. Duncan -------------- next part -------------- New patches: [Reject package version tags Duncan Coutts **20080509090756 At least until we decide how to deal with them properly. ] { hunk ./Unpack.hs 24 +import Distribution.Version ( Version(..) ) hunk ./Unpack.hs 78 + when (not . null . versionTags . pkgVersion $ pkgId) $ + die "package version tags are not currently allowed" + } Context: [if a package has built, ignore any failures Ross Paterson **20080425154935] [track changes to checkPackage Ross Paterson **20080424003335] [add a meta tag declaring the charset as ISO-8859-1, as that's what Text.XHtml generates Ross Paterson **20080328154601] [make parse warnings fatal Ross Paterson **20080328121040] [update to Cabal 1.3.9 Ross Paterson **20080328120711] [disallow updating an existing package Ross Paterson **20080328120600] [generate 00-index.tar.gz asynchronously Ross Paterson **20080302105639] [prune the search for cabal files to make it go faster Ross Paterson **20080302105432] [add small latest-versions lister Ross Paterson **20080221134229] [use absolute filenames when looking for packages Ross Paterson **20080221124040] [longer label on the search button Ross Paterson **20080221123956] [simple implementation of tags, starting with upload info Ross Paterson **20080216021131] [swap arguments to extraChecks Ross Paterson **20080214182808] [fix warning Ross Paterson **20080214182753] [Update to latest Cabal lib API and use new package checking code Duncan Coutts **20080213201347 Compiles but otherwise totally untested. ] [remove private copies of functions now in ghc 6.8 Ross Paterson **20080212011430] [introduce PublicFile for files visible through the web Ross Paterson **20080212005643] [refactoring of upload and check scripts Ross Paterson **20080211131109] [unpack the whole directory, not just the .cabal file Ross Paterson **20080211131009] [add a Google search box to the package list page Ross Paterson **20080203021954] [swap depends-on and required-by maps Ross Paterson **20080202012507] [list successful and unsuccessful builds, with logs Ross Paterson **20080126013443] [blacklist Application, Tool and Type categories Ross Paterson **20071213074800] [add author Ross Paterson **20071213074632] [correct and simplify the library and programs test Ross Paterson **20071210104009] [capitalize category names Ross Paterson **20071130143321] [merge category names that differ only in case Ross Paterson **20071130142342] [render equality constraints concisely Ross Paterson **20071128005652] [ignore case when sorting lists of dependent packages Ross Paterson **20071120123549] [display dependencies in disjunctive normal form Ross Paterson **20071024225216] [Oops, need the flattened package description to get exposed modules and executables Ross Paterson **20071024070848] [use GenericPackageDescription instead of PackageDescription Ross Paterson **20071024064933] [now need Cabal >= 1.2.1 Ross Paterson **20071021155643] [update for Cabal 1.2.1 Ross Paterson **20071021155322] [cabal packaging (based on work of Trevor Elliott) Ross Paterson **20071019124210] [also install search Ross Paterson **20070909185526] [Added search functionality (by Sascha B?hme), but not yet in main menu Ross Paterson **20070909140603] [update for Cabal-1.2 Ross Paterson **20070907234506] [ensure the package list contains latest versions, plus some refacting Ross Paterson **20070723204248] [add link to build log to package page Ross Paterson **20070720124702] [minor build updates Ross Paterson **20070617213315] [fix rendering of identifiers Ross Paterson **20070617213249] [add missing file Ross Paterson **20070530140019] [bugfix for previous commit Ross Paterson **20070510142803] [fix error in building index Ross Paterson **20070508165611] [include a package in the list only if it has a Cabal file Ross Paterson **20070506180938] [change the directory layout of the HackageDB data Ross Paterson **20070506151844 Put version in a separate directory (to simplify future expansion). This will not affect users of the web interface, but will be a breaking change for those who reference the files directly, notably cabal-install. Here's how the positions of the files of the binary package change (-> denotes a symbolic link): Old layout New layout -------------------------------------------------------------------- binary/binary-0.2.cabal binary/0.2/binary.cabal binary/binary-0.2.tar.gz binary/0.2/binary-0.2.tar.gz binary/binary-0.2.misc/doc/html/ binary/0.2/doc/html/ binary/binary-0.3.cabal binary/0.3/binary.cabal binary/binary-0.3.tar.gz binary/0.3/binary-0.3.tar.gz binary/binary-0.3.misc/doc/html/ binary/0.3/doc/html/ binary/latest.misc -> binary-0.3.misc binary/latest -> 0.3 ] [catch "Unclassified" category Ross Paterson **20070307011355] [use local copy of Cabal logo Ross Paterson **20070225125801] [make "recent additions" a generated page instead of a CGI script Ross Paterson **20070220235702] [tweaks to package list Ross Paterson **20070220235601] [generate RSS feed of recent updates Ross Paterson **20070214185538] [bug fix: show preview even if no warnings Ross Paterson **20070213180708] [check-pkg also returns plain text if requested Ross Paterson **20070213001039] [for plain text clients, return only the warnings Ross Paterson **20070211171633] [use CGI type synonym Ross Paterson **20070210152353] [refactor pkgBody arguments as a record Ross Paterson **20070208194243] [strip executables Ross Paterson **20070207233429] [mark property table Ross Paterson **20070207233402] [point to accounts page Ross Paterson **20070207230638] [install upload-pkg in the correct place Ross Paterson **20070206001525] [new location .misc/doc for docs Ross Paterson **20070205004623] [versioned haddock documentation Ross Paterson **20070203202526] [if PACKAGE/doc/html exists, module names are links into it Ross Paterson **20070203170215 (Generation of haddock documentation is not yet automated, though) ] [minor refactoring Ross Paterson **20070202121300] [change package links from pkg/vers to pkg-vers Ross Paterson **20070201143905] [package-ids are unambiguous Ross Paterson **20070201132112] [allow version tags (they seem harmless) Ross Paterson **20070201131251] [trim long synopses in package list Ross Paterson **20070201100052] [tag category list Ross Paterson **20070131121652] [some re-arrangement Ross Paterson **20070131003654] [add category index to package list Ross Paterson **20070130180021] [tweak Cabal logo Ross Paterson **20070129130941] [add Cabal branding to package page Ross Paterson **20070129122133] [mark package lists with an element class Ross Paterson **20070129092724] [revert to textual indication of package type Ross Paterson **20070129080416] [cleanup Ross Paterson **20070129025127] [more compact presentation of package list Ross Paterson **20070129021339] [show other versions on package page Ross Paterson **20070129020229] [move cabalFile to Util Ross Paterson **20070129014325] [pkg-list: only read the most recent Cabal file for each package Ross Paterson **20070129012719] [trim unused functions Ross Paterson **20070129012355] [add export lists for Main modules Ross Paterson **20070129012315] [fix dependency Ross Paterson **20070129005924] [refactoring of version search Ross Paterson **20070129005845] [switch to Text.XHtml Ross Paterson **20070129001802] [more graceful error on missing package Ross Paterson **20070127171227] [minor simplification Ross Paterson **20070127164406] [minor refactoring Ross Paterson **20070127143750] [shuffle stuff between modules Ross Paterson **20070127142603] [change install to scp + mv Ross Paterson **20070127131030] [reword check output Ross Paterson **20070127130746] [add upload.html Ross Paterson **20070126210510] [re-order things on package page Ross Paterson **20070126204017] [minor refactoring Ross Paterson **20070126202141] [tabulate fields Ross Paterson **20070126201050] [remove superfluous thehtml Ross Paterson **20070126174820] [ensure that showPackageId produces the original pkg-id Ross Paterson **20070126150901 Rule out version numbers like "1.00" -> [1,0] -> "1.0". These ought to be rejected by the parser. ] [add boilerplate header to each page Ross Paterson **20070126143901] [remove old form-based parameters to package script Ross Paterson **20070126115030] [tweak category headings Ross Paterson **20070126112054] [make package URLs a bit shorter Ross Paterson **20070125105147 * remove .cgi from CGI scripts in cgi-bin * use PATHINFO instead of form data to identify packages. So now its .../package// or just .../package/ ] [some refactoring Ross Paterson **20070118102430] [append a preview of the package page to the check-pkg output Ross Paterson **20070118003003] [add a README file with overview and install instructions Ross Paterson **20070116153445] [clean up locations a bit Ross Paterson **20070116123020] [parse and markup package descriptions with code stolen from Haddock Ross Paterson **20070116105520] [temporarily downgrade repeated-upload check to a warning Ross Paterson **20070116073009 The check seems like a good idea in the longer term, but It's a bit cumbersome while we're all still experimenting. ] [more compact log lines Ross Paterson **20070113010328] [fix previous commit Ross Paterson **20070112155632] [use errorOutput for error cases Ross Paterson **20070112151251] [basename: strip to slash or backslash (which IE includes in filenames) Ross Paterson **20070112143846] [use a different tmp directory for each process Ross Paterson **20070111010943] [don't accept "Foreign binding" as a category Ross Paterson **20070110233221] [fix stylesheet location Ross Paterson **20070110182307] [change locations to match install on hackage.haskell.org Ross Paterson **20070110170036] [repair post-upload-hook Ross Paterson **20070109224215] [fallback for category: top-level of module hierarchy Ross Paterson **20070109224115] [initial import Ross Paterson **20070109004703 This is a crude first cut at an interface to the Hackage package database: * generating a package list (pkg-list) * page describing a package (package.cgi) * apply basic checks to a Cabal package (check-pkg.cgi) * upload a Cabal package to the database (upload-pkg.cgi) ] Patch bundle hash: ba36c49612699cb94998160a83065de0ae5cb5b2 From ross at soi.city.ac.uk Fri May 9 05:29:24 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri May 9 05:23:24 2008 Subject: version tags In-Reply-To: <1210324326.5824.10.camel@localhost> References: <1210066572.30059.313.camel@localhost> <1210283106.30059.424.camel@localhost> <4823810D.1040900@syntaxpolice.org> <1210288062.5824.3.camel@localhost> <482392B2.8030200@syntaxpolice.org> <1210324326.5824.10.camel@localhost> Message-ID: <20080509092924.GA3793@soi.city.ac.uk> On Fri, May 09, 2008 at 10:12:06AM +0100, Duncan Coutts wrote: > It's clear we should drop the check on the tags from the == test but I'm > not sure if we should also change the showVersion or parseVersion > functions. > > I'm planning on changing the equivalent of showVersion in Cabal to not > display the tags. What are tags for? Should we have them at all? Currently they've been used in: hsgnutls-0.2.3-barracuda hsgnutls-0.2.3.1-barracuda regex-tdfa-0.92-ghc-68-build-fix which seem to be non-maintainer releases. You'd want such versions to be distinguished from the untagged versions. From trac at galois.com Fri May 9 05:34:02 2008 From: trac at galois.com (Hackage) Date: Fri May 9 05:28:02 2008 Subject: [Hackage] #276: Add support for convenience libraries In-Reply-To: <039.485a49f8e972177d4013fdb0eb3f6108@localhost> References: <039.485a49f8e972177d4013fdb0eb3f6108@localhost> Message-ID: <048.f852346392c0b19c2b66e8687be1ec88@localhost> #276: Add support for convenience libraries ----------------------------+----------------------------------------------- Reporter: rl | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * difficulty: normal => project(> week) Comment: There is the constraint that there be at most one installable library so I'm not sure a bool flag is quite right. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan at haskell.org Fri May 9 05:46:29 2008 From: duncan at haskell.org (Duncan Coutts) Date: Fri May 9 05:39:10 2008 Subject: darcs patch: Do not display version tags Message-ID: <20080509093907.8145532412C@www.haskell.org> This is what I'm suggesting. Now is the right time to say if you disagree. Fri May 9 10:44:55 BST 2008 Duncan Coutts * Do not display version tags -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 12797 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080509/d325d06d/attachment.bin From duncan.coutts at worc.ox.ac.uk Fri May 9 05:55:59 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 9 05:48:38 2008 Subject: version tags In-Reply-To: <20080509092924.GA3793@soi.city.ac.uk> References: <1210066572.30059.313.camel@localhost> <1210283106.30059.424.camel@localhost> <4823810D.1040900@syntaxpolice.org> <1210288062.5824.3.camel@localhost> <482392B2.8030200@syntaxpolice.org> <1210324326.5824.10.camel@localhost> <20080509092924.GA3793@soi.city.ac.uk> Message-ID: <1210326959.5824.26.camel@localhost> On Fri, 2008-05-09 at 10:29 +0100, Ross Paterson wrote: > On Fri, May 09, 2008 at 10:12:06AM +0100, Duncan Coutts wrote: > > It's clear we should drop the check on the tags from the == test but I'm > > not sure if we should also change the showVersion or parseVersion > > functions. > > > > I'm planning on changing the equivalent of showVersion in Cabal to not > > display the tags. > > What are tags for? >From the code in base: versionTags :: [String] -- really a bag -- ^ A version can be tagged with an arbitrary list of strings. -- The interpretation of the list of tags is entirely dependent -- on the entity that this version applies to. > Should we have them at all? Getting rid of them is a bit harder because it's a data type defined in the base library. > Currently they've been used in: > > hsgnutls-0.2.3-barracuda > hsgnutls-0.2.3.1-barracuda > regex-tdfa-0.92-ghc-68-build-fix > > which seem to be non-maintainer releases. You'd want such versions to > be distinguished from the untagged versions. Perhaps so, but are tags the right way to do it? If we take them into account for equality then we have to do so for ordering too. We'd have to do something like comparing the sorted lists of tags. If we keep them I'd prefer to just carry the info around but ignore it. If we wanted to support tags we'd have to do it consistently all the way through. They do not translate into distro packages which is a great disadvantage imho. Duncan From Malcolm.Wallace at cs.york.ac.uk Fri May 9 05:59:25 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri May 9 05:55:03 2008 Subject: version tags In-Reply-To: <20080509092924.GA3793@soi.city.ac.uk> References: <1210066572.30059.313.camel@localhost> <1210283106.30059.424.camel@localhost> <4823810D.1040900@syntaxpolice.org> <1210288062.5824.3.camel@localhost> <482392B2.8030200@syntaxpolice.org> <1210324326.5824.10.camel@localhost> <20080509092924.GA3793@soi.city.ac.uk> Message-ID: <20080509105925.7d5248cd.Malcolm.Wallace@cs.york.ac.uk> Ross Paterson wrote: > What are tags for? Should we have them at all? > > hsgnutls-0.2.3-barracuda > hsgnutls-0.2.3.1-barracuda > regex-tdfa-0.92-ghc-68-build-fix I'm guessing that the tag generally indicates a specific set of bugfixes over the original version? And thus does not indicate API changes? So what does the Package Versioning Policy have to say about bugfix-only releases? And whilst we are raising the question of changing the behaviour of comparisons on Data.Version.Version, I would like to repeat the argument I made a few months back, that version X.Y should compare equal to X.Y.0.0.0 (for any sequence of trailing zeroes). Regards, Malcolm From trac at galois.com Fri May 9 10:10:20 2008 From: trac at galois.com (Hackage) Date: Fri May 9 10:04:19 2008 Subject: [Hackage] #277: add data-dir field Message-ID: <042.cb740d1e4e884e9ef58484a233a834b6@localhost> #277: add data-dir field ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- Cabal currently looks for data files to install relative to the source directory, giving the package author no possibility to move them into their own directory without cluttering up the cabal file (you end up writing things like {{{data-files: data/foo, data/bar, data/foobar}}}) and the source (where you'll have to include the {{{"data/"}}} prefix in all calls to {{{getDataFileName}}}). The proposal is to add a {{{data-dir}}} field to the package configuration that specifies a single path which is used as a prefix for all data files in the source directory. The location of the installed files is not affected by {{{data-dir}}}. Notes: * It's impossible to change {{{data-dir}}} to take a list of paths without breaking the {{{Paths_foo}}} module interface. * installation of data files will have to copy source files from a different location, ditto for sdist * installed packages don't change. In particular the {{{Paths_foo}}} module doesn't change. -- Ticket URL: Hackage Hackage: Cabal and related projects From igloo at earth.li Fri May 9 13:01:41 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri May 9 12:55:40 2008 Subject: version tags In-Reply-To: <20080509105925.7d5248cd.Malcolm.Wallace@cs.york.ac.uk> References: <1210066572.30059.313.camel@localhost> <1210283106.30059.424.camel@localhost> <4823810D.1040900@syntaxpolice.org> <1210288062.5824.3.camel@localhost> <482392B2.8030200@syntaxpolice.org> <1210324326.5824.10.camel@localhost> <20080509092924.GA3793@soi.city.ac.uk> <20080509105925.7d5248cd.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20080509170141.GA4569@matrix.chaos.earth.li> On Fri, May 09, 2008 at 10:59:25AM +0100, Malcolm Wallace wrote: > Ross Paterson wrote: > > > What are tags for? Should we have them at all? > > > > hsgnutls-0.2.3-barracuda > > hsgnutls-0.2.3.1-barracuda > > regex-tdfa-0.92-ghc-68-build-fix > > I'm guessing that the tag generally indicates a specific set of bugfixes > over the original version? If they are ignored when comparing version numbers then that means that cabal-install won't update the package to incorporate the bug fix, which sounds bad. Build fixes would be OK from that point of view. Personally I've never liked tags. I'd be happy to remove them, even though the type is in base. Thanks Ian From igloo at earth.li Fri May 9 13:03:07 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri May 9 12:57:05 2008 Subject: version tags In-Reply-To: <1210324326.5824.10.camel@localhost> References: <1210066572.30059.313.camel@localhost> <1210283106.30059.424.camel@localhost> <4823810D.1040900@syntaxpolice.org> <1210288062.5824.3.camel@localhost> <482392B2.8030200@syntaxpolice.org> <1210324326.5824.10.camel@localhost> Message-ID: <20080509170307.GB4569@matrix.chaos.earth.li> On Fri, May 09, 2008 at 10:12:06AM +0100, Duncan Coutts wrote: > > I'm planning on changing the equivalent of showVersion in Cabal to not > display the tags. This sounds like it'll make for some very confusing behaviour differences, as people won't realise that they aren't using exactly the same package. Thanks Ian From trac at galois.com Fri May 9 13:13:03 2008 From: trac at galois.com (Hackage) Date: Fri May 9 13:07:01 2008 Subject: [Hackage] #275: On each package page, give the name of the corresponding debian package In-Reply-To: <042.b836d8a6d74286e6b93ed2956208753a@localhost> References: <042.b836d8a6d74286e6b93ed2956208753a@localhost> Message-ID: <051.7487c25b0bb334e7338990fb4d837420@localhost> #275: On each package page, give the name of the corresponding debian package --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new