September 2011 - cabal-devel

[Hackage] #822: world-file does not support $arch, $os, $compiler
by Hackage 05 Mar '12

05 Mar '12

#822: world-file does not support $arch, $os, $compiler ---------------------------------+------------------------------------------ Reporter: josh | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ In my ~/.cabal/config, I have: install-dirs user prefix: /home/josh/.cabal/install/$arch-$os-$compiler This allows packages for multiple architectures (such as 32-bit and 64-bit) or multiple compilers (such as ghc6 and ghc7) to coexist. It also ensures that after upgrading the compiler, old libraries that won't work automatically disappear. Recent cabal added a "world" file, under ~/.cabal/world. I tried to move this to the same directory, by adding: world-file: /home/josh/.cabal/install/$arch-$os-$compiler/world However, this generated the following error: Error while Error while updating world-file. : /home/josh/.cabal/install/$arch-$os-$compiler/: openNewBinaryFile: does not exist (No such file or directory) From this, I'd guess that cabal doesn't support those variables in world- file like it does in prefix. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/822> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #889: Add option to list recursive dependencies of a package along with their licenses
by Hackage 05 Mar '12

05 Mar '12

#889: Add option to list recursive dependencies of a package along with their licenses ---------------------------------+------------------------------------------ Reporter: joeyadams | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ It should be possible to list all of the dependencies of a package, including their licenses. This would be useful for: * Developers writing proprietary applications. * Developers who don't want their liberally-licensed libraries to be "upgraded" to the GPL or similar by subtle dependencies. Attached is a simple patch that makes cabal-install list this information when the verbosity level is 2 or higher. Sample usage: {{{ $ cabal install --verbose=2 --dry-run gnutls Reading available packages... Resolving dependencies... base BSD3 bytestring BSD3 ffi BSD3 ghc-prim BSD3 gnutls GPL (Just (Version {versionBranch = [3], versionTags = []})) integer-gmp BSD3 monads-tf BSD3 rts BSD3 transformers BSD3 In order, the following would be installed: monads-tf-0.1.0.0 (new package) gnutls-0.1 (new package) }}} This is a quick hack, as I am not familiar with the Cabal codebase. This should probably be wrapped as a {{{--list-licenses}}} command line switch. Pretty-printing licenses would be a plus. I am already finding this feature useful, and hope others will too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/889> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #665: Confusion situation when linking ./dist/setup/setup is interrupted
by Hackage 05 Mar '12

05 Mar '12

#665: Confusion situation when linking ./dist/setup/setup is interrupted ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ If one accidentally interrupts cabal when it's linking `./dist/setup/setup` then you can end up with the file existing it not being executable. This leads to a confusing situation for the user. Running `cabal install` or `cabal configure` will fail silently. Running with -v indicates that something returns exit code 127. This corresponds to a permission error when trying to execute `./dist/setup/setup` Two improvements could be made: * Report the failure to execute `./dist/setup/setup` * If ghc is interrupted when creating `./dist/setup/setup`, cabal should delete the file, if it exists. That way, cabal will recompile on the next invocation. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/665> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #799: ./dist/setup/setup without execute bit causes cabal to exit silently with code 127
by Hackage 05 Mar '12

05 Mar '12

#799: ./dist/setup/setup without execute bit causes cabal to exit silently with code 127 ---------------------------------+------------------------------------------ Reporter: rrnewton | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I ran into this one thanks to Dropbox. All my cabal commands started to fail in the same way all of a sudden (no output, error code 127). A cabal clean -v3 revealed the problem and a chmod +x fixed it. $ cabal clean -v3; echo $? Using external setup method with build-type Custom Creating ./dist/setup (and its parents) Using Cabal library version 1.8.0.6 Using ./Setup.hs as setup script. ./dist/setup/setup clean --verbose=3 127 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/799> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #669: Allow cabal-install's package build location to be set
by Hackage 05 Mar '12

05 Mar '12

#669: Allow cabal-install's package build location to be set ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Apparently some systems mount /tmp such that one cannot create and run executables. This is clearly problematic for cabal-install because it needs somewhere to build packages. http://article.gmane.org/gmane.comp.lang.haskell.cafe/73517 It may be useful for cabal-install to have a config setting to specify where to do package builds (for downloaded packages). If not specified this would default to the temp dir as now. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/669> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #670: cabal-install should warn about common problem after installing progs
by Hackage 05 Mar '12

05 Mar '12

#670: cabal-install should warn about common problem after installing progs ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ There are a few common problems have when installing programs. * target bindir (or symlink-bindir) is not on the `$PATH` so they cannot run the program after installation. * target bindir is on the `$PATH` but the installed program is masked by the presence of the same named prog in a dir that is earlier on the `$PATH`. For example `/usr/local/bin/cabal` and `~/.cabal/bin/cabal`, the latter might have just been installed but the earlier one will still be picked up. * the shell keeping a cache of name -> path and so not picking up a new program. Eg in the above example, even if `~/.cabal/bin/` comes first on the `$PATH`, if bash has the mapping `cabal` -> `/usr/local/bin/cabal` then it will not notice when `~/.cabal/bin/cabal` is installed. The fix here is to run `hash -r`. The only time we might want to tell users to run `hash -r` is if the program did not previously exist and if it gets installed in a location that is earlier on the `$PATH` than an existing installed instance (which may thus be in the cache). Sadly we cannot query sh to find out what its cache holds. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/670> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #672: 'cabal init' command should allow for multiple entries in the Category field
by Hackage 05 Mar '12

05 Mar '12

#672: 'cabal init' command should allow for multiple entries in the Category field ---------------------------------+------------------------------------------ Reporter: byorgey | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: minor | Keywords: init, categories Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ The .cabal format allows multiple categories (e.g. Data, Network, Math, etc.) to be listed in the Category field, but the 'cabal init' interactive mode only lets the user choose a single category. It would be nice to allow the user to choose multiple categories. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/672> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #673: cabal init: fail gracefully if bogus files are found during recursive search for source code
by Hackage 05 Mar '12

05 Mar '12

#673: cabal init: fail gracefully if bogus files are found during recursive search for source code ---------------------------------+------------------------------------------ Reporter: byorgey | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: init, search, file, crash Difficulty: easy (<4 hours) | Ghcversion: 6.12.1 Platform: Mac OS | ---------------------------------+------------------------------------------ cabal init does a recursive search looking for things that look like Haskell modules to be added to the exports list. The following error messages were reported by Ivan Miljenovic: {{{ cabal: /scratch/ghc-6.12.1/distrib/installer-scripts/MacOS: does not exist cabal: /tmp/pulse-a7kaqGHss6Yh/native: inappropriate type }}} Not sure exactly what causes these errors, but in any case cabal init should not crash. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/673> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #681: cabal-install init should not overwrite files without good reason
by Hackage 05 Mar '12

05 Mar '12

#681: cabal-install init should not overwrite files without good reason ---------------------------------+------------------------------------------ Reporter: ezyang | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ If you run "cabal init" in a directory with an already existing .cabal file, it will happily overwrite the old version without asking you. It should detect that a file exists and ask you before writing it out (or even prompting you for info). Alternatively, it could fill up it's defaults using the existing .cabal file. Furthermore, if you pass -n for non-interactive mode, cabal can't ask whether or not the user wanted to overwrite, so probably adding a --force flag is in order. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/681> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #682: 'cabal init' should try to set 'main-is' for executables
by Hackage 05 Mar '12

05 Mar '12

#682: 'cabal init' should try to set 'main-is' for executables ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Currently, `cabal init` will find modules and add them to the `exposed- modules` of a library. It should try to do something similar for executables. The `main-is` field is required for executables and any `other-modules` also need to be listed. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/682> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1