[Haskell-cafe] Re: Cabal dependency hell
creswick at gmail.com
Thu Mar 11 11:54:15 EST 2010
On Mon, Mar 8, 2010 at 2:31 PM, Maciej Piechotka <uzytkownik2 at gmail.com> wrote:
> On Mon, 2010-03-08 at 15:37 +0100, Marc Weber wrote:
>> We can't expect package maintainers to test everything.
>> So it must be people like you and me who fixes those changes.
> Well. Except that it require bumping versions. Which according to
> hackage policy requires to fork a project (which makes it pointless in
> the first place)
This isn't quite that dire -- I've adopted the following practice when
I encounter a cabal dependency issue:
(a) identify the problem (eg: observing `cabal install foo` fails)
(b) get the source via hackage: `cabal unpack foo`
(c) fix the unpacked version, and increment the version number by
adding a new level of detail (so, 3.1.0 becomes 188.8.131.52). This
version number never leaves my system -- it only exists to keep my
(d) if possible, verify that the problem still exists in the
project's actual source control
(e) email the maintainer, and if possible, including a patch to the
current head of the revision control system for the project.
So far, it's worked pretty well :) Everyone I've sent patches to has
been very responsive and helpful, often pushing updated versions to
hackage by the end of the day.
>> The way to go is make hackage allow changing constraints on the fly
>> notifying the author that he can update his repository.
You can, at times, do this by forcing constraints via cabal command
line flags, or by installing packages with a version specification.
$ cabal install foo-1.2.3
will install that specific version of foo.
>> This will work in most cases.
>> Bumping versions because a dependency has changed is bad as well.
>> This will cause to much overhead (and it dosen't solve the problem
>> because the old package is still wrong).
>> Specifying dependencies must be decoupled from bumping versions.
>> It's because dep specs do depend on the "world" which can change..
>> At least that's what I think.
> Hmm. When I was returning home I thought about some wiki-like system
> that would allow to say 'Package X is compatible/not compatible with Y'.
> Possibly something like:
> - Only the 'sure' deps are installed in default mode
> - When in 'expert' mode I can install any package which has not been
> marked as incompatible
> Then I can say that I tested built and:
> - It failed to built
> - It failed the automatic tests (if they exists)/does not work
> - It success
> So if there is versions:
> 0.7 0.8 0.9 1.0 1.0.1 1.1 1.2 1.3 1.4
> - 0.8 failed to built
> - >=1.0 <1.1 was marked by author
> - 1.1 was marked as success
> - 1.3 failed to build
> - In default/normal mode it can be used with 1.0, 1.0.1 and 1.1
> - In expert mode 0.9 and 1.2 can be installed in addition to above
> - Any version can be installed in 'I'm feeling lucky' mode when I
> explicitly say package to ignore some restriction
> Possibly it is needed to collect user karma (or possibly already account
> verification is sufficient).
>> If you're interested in Nix and hack-nix I can show you how everything
>> works using an SSH session.
> Ekhm... SSH?
>> Marc Weber
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe