June 2008 - cabal-devel

[Hackage] #292: warnings in Paths_pkgname module on windows
by Hackage 12 Aug '08

12 Aug '08

#292: warnings in Paths_pkgname module on windows ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: minor | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.2 Platform: Windows | ----------------------------------+----------------------------------------- If you build the `Paths_pkgname` module that Cabal generates on windows then you get these kinds of warnings: {{{ dist\build\autogen/Paths_cabal_install.hs:12:0: Warning: Module `Data.Maybe' is imported, but nothing from it is used, except perhaps instances visible in `Data.Maybe' To suppress this warning, use: import Data.Maybe() dist\build\autogen/Paths_cabal_install.hs:19:0: Warning: Definition but no type signature for `prefix' Inferred type: prefix :: [Char] dist\build\autogen/Paths_cabal_install.hs:20:0: Warning: Definition but no type signature for `bindirrel' Inferred type: bindirrel :: [Char] dist\build\autogen/Paths_cabal_install.hs:73:14: Warning: This binding for `p' shadows an existing binding In a case alternative dist\build\autogen/Paths_cabal_install.hs:80:9: Warning: This binding for `path' shadows an existing binding In a case alternative }}} It'd be nice if we generated code that gave no warnings so that people could make `-Wall` clean packages on Windows. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/292> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #288: the package indexes are very slow
by Hackage 12 Aug '08

12 Aug '08

#288: the package indexes are very slow ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ In a large run, eg trying to make a plan to install 560 packages from hackage: {{{ $ cabal install --dry-run $(cat pkgs) }}} it turns out (according to the ghc profile), 91% of the time is spent reading the index of installed and available packages. The ghc package index is a couple of massive text files in `Read/Show` format so that takes for ever to read. The available package index is the tarball of .cabal files and our .cabal file parser is really slow. For smaller runs it's not so bad: {{{ $ cabal install --dry-run xmonad }}} since we only have to inspect the subset of the available package index that make up xmonad's transitive deps (any versions thereof), so that allows us to avoid forcing most of the index. http://hackage.haskell.org/trac/ghc/ticket/2089 might help us, but then again maybe not if we still have to parse the result of calling ghc-pkg since that will give us another text format. For our own package index, perhaps we should be generating a cache in some other format when we download the package index. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/288> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[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] #295: ld-options parsing treats , as separator
by Hackage 29 Jul '08

29 Jul '08

#295: ld-options parsing treats , as separator ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Say we've got X11.buildinfo.in: {{{ ld-options: @X_LIBS@ @LDFLAGS@ }}} and imagine that someone has all kinds of crazy `LDFLAGS`: {{{ LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--hash-style=gnu -Wl,-z,relro -Wl ,--as-needed -Wl,-z,now" }}} Can you guess what happens? We end up parsing that as: {{{ ldOptions = ["-Wl", "-O1", "-Wl", "--sort-common", "-Wl", "--hash-style=gnu", "-Wl", "-z", "relro", "-Wl", "--as-needed", "-Wl", "-z", "now"] }}} This is because the parser for the `ld-options` field is defined using `listField` which uses `parseOptCommaList` which uses space and `','` as value separators. We should use just spaces for this field and also for `cc-options` and `cpp-options`. If we make this change we'll have to check that we're not going to break things for existing .cabal files that might use ',' as a separator. Will require an audit of .cabal files on hackage. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/295> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[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] #296: Cabal should tell hsc2hs to use gcc as cc, not ghc
by Hackage 24 Jul '08

24 Jul '08

#296: Cabal should tell hsc2hs to use gcc as cc, not ghc ----------------------------+----------------------------------------------- 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: | ----------------------------+----------------------------------------------- The version of hsc2hs that gets bundled with ghc uses ghc by default as the C compiler. The benefit is that we can pass `-package` flags through to ghc and have ghc look up the appropriate C includes and other cc options that are supposed to be used with that package. However it also causes no end of problems. For example, we need to know if the version of hsc2hs we're using actually uses ghc underneath or gcc, because if it's ghc then we have to doubly escape all the cc options that we want to pass through to gcc. It also means that when hsc2hs invents extra -F flags it fails because ghc does not understand that flag (see http://hackage.haskell.org/trac/ghc/ticket/2383) The right thing to do is to have Cabal look up the right flags to use from the package database and call hsc2hs with them, using gcc as cc. We do now have access to the package database so that bit is possible. We'll have to find the gcc program which we do not currently do as we use gcc to compile C code. This is closely related to #229. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/296> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #302: 'data-files' field can't be below 'executable' field
by Hackage 24 Jul '08

24 Jul '08

#302: 'data-files' field can't be below 'executable' field ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: low | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: minor | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- Placing the 'data-files' field below the 'executable' field results in an "Unknown fields" error at configure time. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/302> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2