[Haskell-cafe] Re: Cabal dependency hell

[Rogan Creswick]

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 3.1.0.1).  This
version number never leaves my system -- it only exists to keep my
cabal/ghc-pkg consistent!
 (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.

--Rogan

>>
>> 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
>
> And:
>  - 0.8 failed to built
>  - >=1.0 <1.1 was marked by author
>  - 1.1 was marked as success
>  - 1.3 failed to build
>
> Then
>  - 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
>
> Regards
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>