[Hackage] #471: check for ambigious module names
#471: check for ambigious module names ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Consider an example: {{{ build-depends: base, extensible-exceptions }}} The package `base-4.0.0.0` and `extensible-exceptions-0.1.1.0` both provide the module `Control.Exception`. This means it is impossible to pick both packages as direct dependencies of any single package. We should check for this situation at configure time and/or in cabal- install when planning an installation plan. Actually trying to avoid this situation may be rather tricky and it is not expected to occur often. So a simple check may be sufficient. If it starts to occur often in practice then we could consider trying to get the constraint solver to avoid the situation (perhaps by adding it to the checks for if a package is installable at all, see #420). -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/471 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#471: check for ambigious module names ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: unknown Ghcversion: | Platform: ---------------------------------+------------------------------------------ Old description:
Consider an example:
{{{ build-depends: base, extensible-exceptions }}}
The package `base-4.0.0.0` and `extensible-exceptions-0.1.1.0` both provide the module `Control.Exception`. This means it is impossible to pick both packages as direct dependencies of any single package.
We should check for this situation at configure time and/or in cabal- install when planning an installation plan.
Actually trying to avoid this situation may be rather tricky and it is not expected to occur often. So a simple check may be sufficient. If it starts to occur often in practice then we could consider trying to get the constraint solver to avoid the situation (perhaps by adding it to the checks for if a package is installable at all, see #420).
New description: Consider a example: {{{ build-depends: base, bytestring }}} The package `base-2.1.x` and `bytestring-0.9.x` both provide the module `Data.ByteString`. This means it is impossible to pick both packages as direct dependencies of any single package. We should check for this situation at configure time and/or in cabal- install when planning an installation plan. Actually trying to avoid this situation may be rather tricky and it is not expected to occur often. So a simple check may be sufficient. If it starts to occur often in practice then we could consider trying to get the constraint solver to avoid the situation (perhaps by adding it to the checks for if a package is installable at all, see #420). Comment (by duncan): Changed description to pick a true example. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/471#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#471: check for ambigious module names ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: | Platform: ---------------------------------+------------------------------------------ Changes (by duncan): * difficulty: unknown => hard (< 1 day) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/471#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage