[Haskell-cafe] Package bounds approximation

[Ernesto Rodriguez]

Hi Adam,

Thanks for your suggestion. As I undersdand, the flag looks at the
dependencies specified by the cabal file and simply inverts the package
version solving algorithm to try out older packages before newer. I am
trying to solve a different problem.

Sometime, (at least myself) I specify a particular lower bound in my cabal
file that simply matches whatever was installed when I did cabal install.
The package might work with older versions but checking this manually is a
bit tedious. I would like to have a tool which I can run on my project and
it will give me an approximation of the lowest possible version I can use
for each of the dependencies in my project. If all packages included more
faithful information about what is the lowest possible bound, it would
reduce a lot of dependency hell.

Cheers,

Ernesto


On Wed, Sep 3, 2014 at 5:40 AM, Adam Bergmark <adam at bergmark.nl> wrote:

> It might be interesting to revive this PR:
> https://github.com/haskell/cabal/pull/1309
>
> - Adam
>
>
>
> On Wed, Sep 3, 2014 at 10:48 AM, Ernesto Rodriguez <neto at netowork.me>
> wrote:
>
>> Dear Cafe,
>>
>> I was wondering if there exists a tool to approximate what would be the
>> minimal versions of the dependencies required by a package.
>>
>> I know that calculating this exactly is a bit intractable, but I was
>> considering whether a tool that works as follows would work:
>>
>> 1) Compile the package with known to work dependencies
>> 2) For each version of dependency as d:
>>         For each function in d used by My Package:
>>              * Perform unification of the resulting type when compiled
>> with known to work dependencies
>>                and the type exported by the api of the version of the
>> dependency in consideration.
>>          If all unifications succeeds, mark the version as compatible,
>> incompatible otherwise
>>
>> This approximation is obviously not complete. Nevertheless, I would like
>> to get opinions about whether this would be a good/useful/feasible
>> approximation? Does the current GHC api export enough functionality for
>> this package to be feasible? Are there alternatives? I was consider doing
>> this as my `hack` during the high energy, intense no-sleep jacobsHack!
>> <http://jacobshack.com> hackathon, do you think it would be a good idea?
>>
>> Thank you for the opinions and best regards,
>>
>> Ernesto Rodriguez
>>
>> --
>> Ernesto Rodriguez
>>
>> Masters Student
>> Computer Science
>> Utrecht University
>>
>> www.netowork.me
>> github.com/netogallo
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>


-- 
Ernesto Rodriguez

Masters Student
Computer Science
Utrecht University

www.netowork.me
github.com/netogallo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140903/ff8b50d1/attachment.html>