May 2008 - cabal-devel

[Hackage] #198: cabal install foo should upgrade foo if there's a newer version
by Hackage 12 Aug '08

12 Aug '08

#198: cabal install foo should upgrade foo if there's a newer version ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ if I have foo-1.0 installed, and foo-2.0 is available, "cabal install foo" should upgrade foo to version 2.0 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/198> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 8

[Hackage] #175: cabal-install needs a new package dependency resolution algorithm
by Hackage 12 Aug '08

12 Aug '08

#175: cabal-install needs a new package dependency resolution algorithm ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | ----------------------------+----------------------------------------------- The current package dependency algorithm is pretty simple. It's main failing is that it cannot backtrack if it finds the solution is impossible. What we would like is a new dependency resolution algorithm that can backtrack. We would also like to be able to configure policy issues separately, perhaps as a parameter. It may also be handy to let users or the system add extra version constraints. The input is the set of available packages and the output is a list of packages to install, and the assignment of configuration flags to use for each one. As for the policy input, this might take the form of a function that picks between possible dependencies in a slot, this could then allow us to make choices like preferring installed packages over the latest available package version, or vica versa. See also symptoms of the existing system: * bug #168 -- lack of configurable policy * bug #174 -- lack of backtracking -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/175> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #267: cabal upload has poor error messages (just an HTTP response code)
by Hackage 12 Aug '08

12 Aug '08

#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 | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- All these bugs are against the homeomorphic library I have written. To play along, you can do darcs get --partial http://www.cs.york.ac.uk/fp/darcs/homeomorphic $ cabal upload dist E:\Neil\homeomorphic>cabal upload dist\homeomorphic-0.1.tar.gz Hackage username: NeilMitchell Hackage password: yoda Uploading dist\homeomorphic-0.1.tar.gz... ERROR: dist\homeomorphic-0.1.tar.gz: 400 Error in upload 400 error in upload - not the worlds most helpful error message... Duncan says: Indeed. There is an error message available but I'm not sure how we get at it. Any ideas Ross? Another ticket for this one. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/267> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #213: allow wildcards in data-files or extra-source-files?
by Hackage 29 Jul '08

29 Jul '08

#213: allow wildcards in data-files or extra-source-files? ----------------------------+----------------------------------------------- Reporter: duncan | 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: | ----------------------------+----------------------------------------------- Some packages end up with very very long fields for data-files or extra- source-files. Is this a problem? Should we allow some kind of globing to make it a bit less verbose? {{{ extra-source-files: cbits/*.h c-sources: cbits/*.c }}} On the other hand, there is a danger with globing that you pick up too many files. Perhaps we can counter that by making the globing rather restrictive, like no subdirectory recursion, and only allowing *'s in the final directory component, so no {{{data/*/*}}} patterns. Is there a sweet spot that allows conciseness without including too much accidentally? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/213> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #232: implement extended syntax for package version ranges
by Hackage 29 Jul '08

29 Jul '08

#232: implement extended syntax for package version ranges ----------------------------+----------------------------------------------- Reporter: duncan | Owner: nominolo 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: | ----------------------------+----------------------------------------------- Revised proposal: http://www.haskell.org/pipermail/cabal- devel/2008-January/001786.html Reproduced here: In order to make it easy for package package authors to describe correct and robust dependencies we (Duncan Coutts and I) propose the following syntactical extension to version range specifications in package files. == Wildcards == {{{ ~ 1.2.* ~~> >= 1.2 && < 1.3 }}} in general {{{ ~ x.y.* ~~> >= x.y && < x.(y+1) }}} The "~" operator should be read as "in the range of". Another option would have been "-", but this is used to specify exact versions in other parts of the Cabal infrastructure , e.g., "cabal install xmonad-0.5". This is the most common specification of package dependencies. The assumption is that changes in the last version number indicate only backwards compatible changes, as is suggested in the new package versioning policy [1]. The use of "*" matches the common usage as a wildcard character. == Upward Ranges == {{{ ~ 1.2.1+ ~~> >= 1.2.1 && < 1.3 }}} in general {{{ ~ x.y.z+ ~~> >= x.y.z && < x.(y+1) }}} The idea here is that sometimes packages need a certain patch level or, as in Cabal's case, a stable release and possible further bugfixes. In those cases the wildcard notation is too liberal, however the explicit range description would be too noisy (and possibly error prone). (Also, using "+" instead of "*" serves as better visual distinction.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/232> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #258: case confusion - cabal vs Cabal
by Hackage 23 Jun '08

23 Jun '08

#258: case confusion - cabal vs Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- The darcs repo for Cabal is at darcs.haskell.org:/home/darcs/cabal yet it contains a file Cabal.cabal, which indeed claims that the name of the package is Cabal. This confusion of letter case is causing problems for me. Can we agree that Cabal is capitalised, and rename the repo dir? That seems like the simplest way to achieve consistency. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/258> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #265: Cabal field stability not useful
by Hackage 22 Jun '08

22 Jun '08

#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 | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- As it stands, the 'stability:' field isn't very useful. Hardly anyone uses it, and even if someone does, it does minimal good, since it's just an arbitrary string. I propose it be changed into an enumerated type, like license: is. That way we could do things like have cabal-install warn when installing unstable, add view filters to Hackage, and so on. This is all stuff that'd be pretty ad-hoc if done on whatever strings package authors were writing. Now, what should the entries be? Ideally, we'd like to be able to say a couple things. We'd like to say that a release is Stable, or Unstable. For example, HaXml's most recent package on Hackage is Unstable, and that's why Goerzen's Hpodder uses an older, Stable, version of HaXml. But we'd also like to express not just stability, but feature-completeness - Alpha, Beta, Release. It's perfectly sensible to have a piece of software which is a Stable Alpha; early XMonads were very stable (I was using it from the first public repo patches, and it only ever crashed a handful of times, less than StumpWM). And equally I'd suggest you could have Unstable Betas. Most cabal files I've seen using stability: seem to use 'Stable', 'Unstable', 'Experimental', 'Alpha', or 'Beta'. (Although GTK2HS seems to be using 'Stability: provisional'). So perhaps one could make the stability field accept 0-2 entries: one from Stable/Unstable, and one from Experimental/Alpha/Beta/Release. -- gwern -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/265> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #187: Paths_pkgname module is hard to use in a library
by Hackage 12 Jun '08

12 Jun '08

#187: Paths_pkgname module is hard to use in a library ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.1 Platform: Linux | ------------------------------+--------------------------------------------- Most users of the auto-generated {{{Paths_pkgname}}} module are programs. With GHC at least they can get away with not specifying the {{{Paths_pkgname}}} in the {{{Other-Modules}}} field. Get away with in the sense that it does not lead to linker errors because {{{ghc --make}}} does dependency chasing and links in all the necessary .o files. However for a library you must specify every module in {{{Exposed- Modules}}} or {{{Other-Modules}}} or one does get linker errors when you try to use the packages. That's because the missing module's .o files will not have been included in the library .a archive. See bug #128. So for a library one must specify {{{Other-Modules: Paths_pkgname}}} but then of course Cabal cannot find that module since it is not in the normal source directories but in {{{dist/build/autogen}}}. So people have to hack around it by adding {{{dist/build/autogen}}} to the {{{Hs-Source-Dirs}}} field. Obviously that's rather unsatisfactory. Probably the right solution is for Cabal to automatically add that directory to the end of the source dir search path. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/187> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #285: hackage trac should permit registration
by Hackage 11 Jun '08

11 Jun '08

#285: hackage trac should permit registration ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- hackage trac does not seem to have a "register" option (compare hackage trac with ghc trac). individual logins are nice because: - gives individual rather than anonymous reporters - one place less to support spam email harvesters (account name instead of full email address) - "register" is always there, hence easy to find, unlike the hint hidden on the trac home page that hackage is still abusing the haskell' trac.. (might lower the barrier to file report/suggestion tickets) Duncan comments: We used to have that and got horribly spammed. Apparently for the ghc trac they've worked out how to do that without getting spammed so presumably we could do the same. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/285> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #230: setup haddock ignores LANGUAGE CPP pragma
by Hackage 09 Jun '08

09 Jun '08

#230: setup haddock ignores LANGUAGE CPP pragma ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | 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: | ----------------------------------+----------------------------------------- `setup haddock` preprocesses sources with cpp if `CPP` is included in the `extensions` field, but not if a source file starts with {{{ {-# LANGUAGE CPP #-} }}} This is confusing, because that works with `setup build`. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/230> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3