September 2008 - cabal-devel

[Hackage] #358: cabal-install bootstrap.sh missing some dependencies
by Hackage 15 Jan '09

15 Jan '09

#358: cabal-install bootstrap.sh missing some dependencies ----------------------------------+----------------------------------------- Reporter: Araneidae | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- The following dependencies are not checked for or installed by bootstrap.sh: `network`, `parsec`, `mtl`. On a fresh install of ghc 6.8.2 on Ubuntu 8.04 these packages are missing and need to be installed manually. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/358> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #359: Warn if package index is older than X days
by Hackage 14 Jan '09

14 Jan '09

#359: Warn if package index is older than X days ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- People often trip up with getting older versions of packages than they expected because their package index is out of date. This is because people have to manually run `cabal update` occasionally. It would be nice if this could be done automatically, though we also need to support offline operation. In the mean time we should at least warn if the package index looks rather old. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/359> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #348: Wrong login details for `cabal upload' is not handled gracefully
by Hackage 12 Jan '09

12 Jan '09

#348: Wrong login details for `cabal upload' is not handled gracefully ----------------------------+----------------------------------------------- Reporter: chrisdone | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- Example: [[BR]] chris@chrisdesktop:~/haskell/lojban$ cabal upload dist/lojban-0.0.tar.gz[[BR]] Hackage username: foo[[BR]] Hackage password: bar[[BR]] Uploading dist/lojban-0.0.tar.gz...[[BR]] cabal: bsAuthGen wanted -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/348> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #342: Allow automatic resolving of conditionals on more than just build-depends
by Hackage 07 Jan '09

07 Jan '09

#342: Allow automatic resolving of conditionals on more than just build-depends -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- We have several classes of dependency that we can express in .cabal files. The most obvious is other Haskell packages via the `build-depends` field. The others are: * C libs (`extra-libraries`) * C headers (`includes`) * other build tools (`build-tools`) * pkg-config packages (`pkgconfig-depends`) * MacOS X frameworks (`frameworks`) And we may end up with more, like Windows assemblies. If we know (by domain-specific means) what dependencies are available then we should be able to automatically resolve flag conditions that depend on them. So each one is it's own namespace and they have different representations of keys. Most use a name and some a version too. Currently `finalizePackageDescription` takes a `Maybe (PackageSet pkg)` as a way of testing if deps are available. We should generalise this to a dep testing function (which is essentially what `finalizePackageDescription` turns it into internally) on a type that has alternatives for each of the dependency namespaces. If we only had to generalise it for package constraints we might go for `Dependency -> [PackageId]` but how should we do it when we have multiple namespaces and some require version constraints and others do not. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/342> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #327: should require minimum c2hs version of 0.15
by Hackage 22 Dec '08

22 Dec '08

#327: should require minimum c2hs version of 0.15 ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- Cabal does not work with c2hs older than 0.15. With older c2hs versions the .hs file ends up in the wrong location in the build tree. If we find that c2hs is needed for the build then we should check that it meets this minimum version. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/327> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #340: Deprecate RecordPuns and translate NamedFieldPuns for older ghc
by Hackage 16 Dec '08

16 Dec '08

#340: Deprecate RecordPuns and translate NamedFieldPuns for older ghc ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.6 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- The `RecordPuns` extension was accidentally added. In ghc-6.10 it will be deprecated and done as an alias for `NamedFieldPuns`. See: http://hackage.haskell.org/trac/ghc/ticket/2320 That means people will use `NamedFieldPuns` instead which will then not work with older ghc. Cabal should encourage users to switch to `NamedFieldPuns` but should translate this into `RecordPuns` when calling older ghc versions. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/340> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #336: --constraint flag only used for configure not for install/upgrade dep planning
by Hackage 16 Dec '08

16 Dec '08

#336: --constraint flag only used for configure not for install/upgrade dep planning ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ It would be relatively easy to support the `--constraint=DEP` flag as an input to install/upgrade dependency planning. We should do it because it's useful and it's confusing that it's not supported. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/336> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #203: Find out what we can learn from ruby gems
by Hackage 15 Dec '08

15 Dec '08

#203: Find out what we can learn from ruby gems ---------------------+------------------------------------------------------ Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: misc | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------+------------------------------------------------------ [http://rubygems.org/ Ruby Gems] is superficially a similar system for Ruby as Cabal + cabal-install + HackageDB is for Haskell. This task is to do some research to compare two systems to find out what lessons we can learn from Ruby Gems. The findings should be recorded on the [wiki:RubyGems] wiki page -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/203> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #363: Where do downloaded files end up?
by Hackage 02 Dec '08

02 Dec '08

#363: Where do downloaded files end up? ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Even with verbose=3 the cabal command doesn't say where it puts the downloaded file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/363> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #209: Implement "package()" configurations predicate
by Hackage 08 Nov '08

08 Nov '08

#209: Implement "package()" configurations predicate ----------------------------+----------------------------------------------- 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: Linux | ----------------------------+----------------------------------------------- We often have to write things like: {{{ flag splitBase description: Choose the new smaller, split-up base package. library if flag(splitBase) build-depends: base >= 3, containers else build-depends: base < 3 }}} Which is verbose and annoying. It would be nicer to say: {{{ library build-depends: base if package(base >= 3) build-depends: containers }}} This is syntactic sugar only. It translates into the existing constructs so no new behaviour is being introduced. It would translate into: {{{ flag _1 library build-depends: base if flag(_1) build-depends: base >= 3 build-depends: containers else build-depends: base < 3 }}} It is described in more detail in this thread: http://www.haskell.org/pipermail/cabal-devel/2007-October/001189.html http://www.haskell.org/pipermail/cabal-devel/2007-November/001336.html -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/209> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7