kazu-yamamoto/cab

A maintenance command of Haskell cabal packages

cab's Issues

Should use -threaded always?

Currently, cab is built with -threaded only on Windows.
On NetBSD, it blocks forever when running some command, such as cab outdated.
It blocks at waitForProcess (invoked with forkIO) in streaming-commons package. [1]

It is mentioned in Haddock of waitForProcess. [2]

GHC Note: in order to call waitForProcess without blocking all the other threads in the system, you must compile the program with -threaded.

So it seems cab should be built with -threaded on other platforms also.

[1] http://hackage.haskell.org/package/streaming-commons-0.1.4.2/docs/src/Data-Streaming-Process.html#streamingProcess
[2] http://hackage.haskell.org/package/process-1.2.0.0/docs/System-Process.html#v:waitForProcess

cab outdated shows packages ahead of Hackage version

I'm not sure if this is intentional, but cab outdated displays packages whose version is ahead of the version on Hackage (i.e., a development version). For example,

> cab outdated
kure 2.16.2 /= 2.16.1

It doesn't really make sense to view that as outdated, in my opinion. A simple fix would be to change the inequality (/=) to (<) in outdated, but perhaps it would be better if the user could custom-tune what is considered outdated via flags.

cab outdated shows smaller sign for greater packages

% cab outdated

Cabal 1.19.2 < 1.18.1.2
HTTP 4000.2.10 < 4000.2.11

1.19.2 < 1.18.1.2?

bug when built with ghc 7.21

when i run: cab outdated

i get the error

cab: Process.hs:(17,15)-(25,7): Missing field in record construction System.Process.Internals.create_group

Request: cab ghci

Is it possible to have a cab ghci command that is a wrapper to cabal-dev ghci except uses the correct sandbox?
So that when you have CAB_SANDBOX_PATH set you run the correct GHCi prompt.

Looking at the code this seems extremely easy, will submit a pull request if I have some time to look through ;)
If you agree on the issue that is?

Update build-depends in .cabal by current modules

You know that `cabal init' generates .cabal and appropriate Build-Depends's field values.
I'm hoping to update these values.
Because these values will change rapidly.

Remove executables with cab uninstall

cab uninstall does not remove executables (e.g., agda and agda-mode) installed in ~/.cabal/bin. This could be useful, but I wonder if it could be dangerous (consider cab uninstall cab, for instance).

Fails to install

$ cabal install cab
Resolving dependencies...
Configuring cab-0.2.10...
Building cab-0.2.10...
Failed to install cab-0.2.10
Last 10 lines of the build log ( /home/whtev/.cabal/logs/cab-0.2.10.log ):
Configuring cab-0.2.10...
Building cab-0.2.10...
Preprocessing library cab-0.2.10...
[1 of 9] Compiling Distribution.Cab.GenPaths ( Distribution/Cab/GenPaths.hs, dist/build/Distribution/Cab/GenPaths.o )
[2 of 9] Compiling Distribution.Cab.Sandbox ( Distribution/Cab/Sandbox.hs, dist/build/Distribution/Cab/Sandbox.o )
[3 of 9] Compiling Distribution.Cab.Utils ( Distribution/Cab/Utils.hs, dist/build/Distribution/Cab/Utils.o )
[4 of 9] Compiling Distribution.Cab.Version ( Distribution/Cab/Version.hs, dist/build/Distribution/Cab/Version.o )
[5 of 9] Compiling Distribution.Cab.VerDB ( Distribution/Cab/VerDB.hs, dist/build/Distribution/Cab/VerDB.o )

Distribution/Cab/VerDB.hs:45:31: Not in scope: `sourceCmd'
cabal: Error: some packages failed to install:
cab-0.2.10 failed during the building phase. The exception was:
ExitFailure 1

GHC version 7.6.3

cab uninstall deletes all MinGW libraries

I uninstalled cairo on Windows one day using cab, then to my horror, I discovered sometime later that I no longer had any library files in my MSYS2 installation! It turns out that cab was responsible:

$ cab uninstall cairo -r
Deleting cairo 0.13.1.0
Deleting C:\Users\ryanscot\AppData\Roaming\cabal\x86_64-windows-ghc-7.10.2\cairo-0.13.1.0-BvHflyquX9N2z5gGhce0bJ
Deleting C:/msys64/mingw64/lib
Deleting C:\Users\ryanscot\AppData\Roaming\cabal\doc\x86_64-windows-ghc-7.10.2\cairo-0.13.1.0

It appears that getDirs is to blame, since it retrieves all library directories that ghc-pkg discovers (including C:/msys64/mingw64/lib, which I definitely do not want to be deleted!), and proceeds to delete them all.

Here was the output of ghc-pkg field cairo library-dirs prior to calling cab uninstall:

$ ghc-pkg field cairo library-dirs
library-dirs: C:\Users\ryanscot\AppData\Roaming\cabal\x86_64-windows-ghc-7.10.2\cairo-0.13.1.0-BvHflyquX9N2z5gGhce0bJ
              C:/msys64/mingw64/lib

cab-0.2.19: Ambiguous occurrence ‘unPackageName’

This may well be fixed in git but 0.2.19 fails to build with ghc-9.2.5:

Distribution/Cab/GenPaths.hs:35:14: error:
    Ambiguous occurrence ‘unPackageName’
    It could refer to
       either ‘Distribution.Cab.Utils.unPackageName’,
              imported from ‘Distribution.Cab.Utils’ at Distribution/Cab/GenPaths.hs:8:63-75
              (and originally defined at Distribution/Cab/Utils.hs:100:1-13)
           or ‘Distribution.PackageDescription.unPackageName’,
              imported from ‘Distribution.PackageDescription’ at Distribution/Cab/GenPaths.hs:10:1-38
              (and originally defined in ‘Distribution.Types.PackageName’)
   |
35 |         nm = unPackageName $ pkgName pkg
   |              ^^^^^^^^^^^^^

To be quite honest I don't use cab personally though we still have it packaged in Fedora.

I can try your recent commit anyway - but maybe you want to push a new release when you find time, thanks. :)

`cab outdated` confusing for multiple installed versions

If I have multiple versions of a package installed, I can't see from cab outdateds output for which I haven't got the latest version installed. E.g.:

$ cab outdated
aeson 0.3.2.7 < 0.3.2.9
...

$ cabal info aeson
* aeson            (library)
    Synopsis:      Fast JSON parsing and encoding
    Versions available: 0.1.0.0, 0.2.0.0, 0.3.0.0, 0.3.1.0, 0.3.1.1, 0.3.2.6,
                        0.3.2.7, 0.3.2.8, 0.3.2.9 (and 6 others)
    Versions installed: 0.3.2.7, 0.3.2.9
    ...

So, aeson isn't really outdated, I just happen to have an old version lying around as well

Parsing invalid version numbers fails with `read: no parse`

$ cab delete text foo
cab: Prelude.read: no parse

This can be a bit confusing, maybe one would expect this to allow deletion of several packages since you don't always need to specify the version number when deleting.

cab delete -r: Prelude.(!!): index too large

I was doing a fairly bug recursive delete and got this error. For what it's worth here's the complete output:

$ cab outdated
Cabal 1.21.0.0 /= 1.20.0.0
QuickCheck 2.6 /= 2.7.3
blaze-html 0.7.0.1 /= 0.7.0.2
blaze-markup 0.6.0.0 /= 0.6.1.0
directory-tree 0.11.0 /= 0.12.0
file-embed 0.0.6 /= 0.0.7
hashable 1.2.1.0 /= 1.2.2.0
http-types 0.8.4 /= 0.8.5
mmorph 1.0.2 /= 1.0.3
mtl 2.1.3.1 /= 2.2.0.1
nats 0.1.3 /= 0.2
pretty-show 1.6.7 /= 1.6.8
primitive 0.5.2.1 /= 0.5.3.0
resourcet 0.4.10.2 /= 1.1.2.2
system-fileio 0.3.12 /= 0.3.13
system-filepath 0.4.10 /= 0.4.11
text 1.1.0.1 /= 1.1.1.2
utf8-string 0.3.7 /= 0.3.8
vector 0.10.9.1 /= 0.10.9.2
V~/r/f/fay master> cab delete text 1.1.0.1
The following packages depend on this. Use the "-r" option.
yesod-routes 1.2.0.6
xmlhtml 0.2.3.2
vault 0.3.0.3
uuid 1.3.3
text-stream-decode 0.1.0.5
test-framework-th 0.2.4
test-framework-hunit 0.3.0.1
test-framework 0.8.0.3
xml 1.3.13
tagsoup 0.13.100
sourcemap 0.1.3.0
shakespeare-text 1.1.0
shakespeare 2.0.0.3
system-fileio 0.3.12
system-filepath 0.4.10
regex-tdfa 1.2.0
path-pieces 0.1.3.1
packdeps 0.4.0.2
network 2.5.0.0
mime-types 0.1.0.4
language-ecmascript 0.16.2
parsec 3.1.5
http-types 0.8.4
hse-cpp 0.1
hlint 1.8.61
uniplate 1.6.12
groom 0.1.2
haskell-src-exts 1.15.0.1
fay-jquery 0.6.0.2
fast-logger 2.1.5
cpphs 1.18.4
polyparse 1.9
cookie 0.4.1.1
cinder 0.4
fay-text 0.3.0.2
case-insensitive 1.2.0.0
blaze-html 0.7.0.1
blaze-markup 0.6.0.0
blaze-builder-enumerator 0.2.0.5
enumerator 0.4.20
blaze-builder 0.3.3.2
aeson 0.7.0.6
unordered-containers 0.2.4.0
attoparsec 0.11.3.4
scientific 0.3.2.1
hashable 1.2.1.0

$ cab delete text 1.1.0.1 -r
Deleting yesod-routes 1.2.0.6
Deleting dirs: /Users/adam/.cabal/lib/x86_64-osx-ghc-7.8.2/yesod-routes-1.2.0.6 /Users/adam/.cabal/share/doc/x86_64-osx-ghc-7.8.2/yesod-routes-1.2.0.6/
Deleting xmlhtml 0.2.3.2
Deleting dirs: /Users/adam/.cabal/lib/x86_64-osx-ghc-7.8.2/xmlhtml-0.2.3.2 /Users/adam/.cabal/share/doc/x86_64-osx-ghc-7.8.2/xmlhtml-0.2.3.2/
Deleting vault 0.3.0.3
Deleting dirs: /Users/adam/.cabal/lib/x86_64-osx-ghc-7.8.2/vault-0.3.0.3 /Users/adam/.cabal/share/doc/x86_64-osx-ghc-7.8.2/vault-0.3.0.3/
Deleting uuid 1.3.3
Deleting dirs: /Users/adam/.cabal/lib/x86_64-osx-ghc-7.8.2/uuid-1.3.3 /Users/adam/.cabal/share/doc/x86_64-osx-ghc-7.8.2/uuid-1.3.3/
Deleting text-stream-decode 0.1.0.5
Deleting dirs: /Users/adam/.cabal/lib/x86_64-osx-ghc-7.8.2/text-stream-decode-0.1.0.5 /Users/adam/.cabal/share/doc/x86_64-osx-ghc-7.8.2/text-stream-decode-0.1.0.5/
Deleting test-framework-th 0.2.4
Deleting dirs: /Users/adam/.cabal/lib/x86_64-osx-ghc-7.8.2/test-framework-th-0.2.4 /Users/adam/.cabal/share/doc/x86_64-osx-ghc-7.8.2/test-framework-th-0.2.4/
Deleting test-framework-hunit 0.3.0.1
Deleting dirs: /Users/adam/.cabal/lib/x86_64-osx-ghc-7.8.2/test-framework-hunit-0.3.0.1 /Users/adam/.cabal/share/doc/x86_64-osx-ghc-7.8.2/test-framework-hunit-0.3.0.1/
Deleting test-framework 0.8.0.3
Deleting dirs: /Users/adam/.cabal/lib/x86_64-osx-ghc-7.8.2/test-framework-0.8.0.3 /Users/adam/.cabal/share/doc/x86_64-osx-ghc-7.8.2/test-framework-0.8.0.3/
Deleting xml 1.3.13
Deleting dirs: /Users/adam/.cabal/lib/x86_64-osx-ghc-7.8.2/xml-1.3.13 /Users/adam/.cabal/share/doc/x86_64-osx-ghc-7.8.2/xml-1.3.13/
Deleting tagsoup 0.13.100
Deleting dirs: /Users/adam/.cabal/lib/x86_64-osx-ghc-7.8.2/tagsoup-0.13.100 /Users/adam/.cabal/share/doc/x86_64-osx-ghc-7.8.2/tagsoup-0.13.100/
Deleting sourcemap 0.1.3.0
Deleting dirs: /Users/adam/.cabal/lib/x86_64-osx-ghc-7.8.2/sourcemap-0.1.3.0 /Users/adam/.cabal/share/doc/x86_64-osx-ghc-7.8.2/sourcemap-0.1.3.0/
Deleting shakespeare-text 1.1.0
cab: Prelude.(!!): index too large

A bug in `cab outdated`

I've installed snaplet-postgresql-simple from the git repository and cab outdated prints

snaplet-postgresql-simple 0.3.0.4 < 0.3.0.3

which seems doubly wrong. Not only that this version is not outdated, but also the symbol should be "greater than".

Pattern match(es) are non-exhaustive

Hello, compiling this package using ghc 9.2.8 I get following warnings:

[6 of 9] Compiling Doc              ( src/Doc.hs, dist/build/cab/cab-tmp/Doc.dyn_o )

src/Doc.hs:23:5: warning: [-Wincomplete-uni-patterns]
    Pattern match(es) are non-exhaustive
    In a pattern binding: Patterns of type ‘[String]’ not matched: []
   |
23 |     cmd:_ = commandNames cmdspec
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[7 of 9] Compiling Commands         ( src/Commands.hs, dist/build/cab/cab-tmp/Commands.dyn_o )
[8 of 9] Compiling Help             ( src/Help.hs, dist/build/cab/cab-tmp/Help.dyn_o )
[9 of 9] Compiling Main             ( src/Main.hs, dist/build/cab/cab-tmp/Main.dyn_o )

src/Main.hs:28:9: warning: [-Wincomplete-uni-patterns]
    Pattern match(es) are non-exhaustive
    In a pattern binding:
        Patterns of type ‘ParsedArgs’ not matched: Left _
   |
28 |     let Right (args,opts0) = pargs
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^

src/Main.hs:32:9: warning: [-Wincomplete-uni-patterns]
    Pattern match(es) are non-exhaustive
    In a pattern binding: Patterns of type ‘[Arg]’ not matched: []
   |
32 |         act:params = args
   |         ^^^^^^^^^^^^^^^^^

src/Main.hs:35:9: warning: [-Wincomplete-uni-patterns]
    Pattern match(es) are non-exhaustive
    In a pattern binding:
        Patterns of type ‘Maybe CommandSpec’ not matched: Nothing
   |
35 |     let Just cmdspec = mcmdspec
   |         ^^^^^^^^^^^^^^^^^^^^^^^
Linking dist/build/cab/cab ...

`cab ghci` can't choose sandboxed packages correctly

If the different versions of dependent package are installed both globally and in sandbox and global version is newer than sandboxed one, then cab ghci loads global one instead of sandbox.

For example, we are writing some package foo and it depends of bar ==0.2.* and following:

$ ghc-pkg list bar
~/.ghc/x86_64-darwin-7.8.3/package.conf.d
  bar-0.2.3.1

$ cabal sandbox hc-pkg list bar
~/haskell/projects/foo/.cabal-sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d
   bar-0.2.1.4

Then, cab ghci loads global bar-0.2.3.1 rather than sandboxed bar-0.2.1.4 and leads to type-error.

cabal repl correctly loads sandboxed version in the same situation, so I think this is not intended behaviour.

support "--reinstall" option

I'm using the cab constantly, but it's to fail with the --reinstall option.

e.g.:

% cab install --reinstall xxxxxx
Illegal options: --reinstall

Please support the --reinstall option.

a problem in 'cab uninstall'

When setting

extra-lib-dirs: /some/extra/lib

in .cabal/config, cab uninstall unnecessarily tries to do rm -rf /some/extra/lib.

The problem could be that Distribution.Cab.Commands.purge calls rm -rf for all the paths in ghc-pkg field pkg library-dirs.

Here is an ad-hoc fix where purge only takes into account the first path of library-dirs.

--- a/Distribution/Cab/Commands.hs      Tue Jan 21 15:30:02 2014 +0900
+++ b/Distribution/Cab/Commands.hs      Sun Feb 09 02:00:26 2014 +0900
@@ -116,7 +116,7 @@
     makeOptList x  = [x]
     queryGhcPkg sandboxOpts field = do
         let options = ["field"] ++ sandboxOpts ++ [name ++ "-" ++ ver, field]
-        unwords . tail . words <$> readProcess "ghc-pkg" options ""
+        (!!1) . words <$> readProcess "ghc-pkg" options ""
     cutTrailing suffix s
       | suffix `isSuffixOf` s = reverse . drop (length suffix) . reverse $ s
       | otherwise             = s

cab get command/alias

In Cabal 1.18, the cabal get command was added to replace cabal unpack. Currently, cab get is not an alias for cab unpack. Also, I'm not sure if you'd want to list get to be the primary command (with unpack as the alias).

cab -s sandbox list does not list sandbox contents

Using ghc-7.4.1 (no haskell platform) and cab-0.1.13 in linux debian the command cab -s sandbox list does not list the sandbox contents.

After looking at the source code found that PkgDB.userPkgs is filtering all the packages which don't have a path prefix as "/home/user/." I'm attaching a patch (when I figure out how to do that) that changes the behavior of userPkgs when a sandbox path is specified in the command line (so the sandbox is not required to be under the user home).

bug when built with ghc 7.21

when i run: cab outdated

i get the error

cab: Process.hs:(17,15)-(25,7): Missing field in record construction System.Process.Internals.create_group