[Haskell-cafe] Package bounds approximation
Alois Cochard
alois.cochard at gmail.com
Wed Sep 3 12:51:27 UTC 2014
Hi Ernesto,
I was looking to solve this problem a while ago, but I didn't found a
satisfactory tool.
What I do atm, is trying to compile using versions of an old haskell
platform (like last year or something...)
I hope that help, and I would to find an automated way of doing it.
Cheers
On Sep 3, 2014 2:35 PM, "Ernesto Rodriguez" <neto at netowork.me> wrote:
> 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
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140903/e1a96de7/attachment.html>
More information about the Haskell-Cafe
mailing list