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 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 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Ernesto Rodriguez Masters Student Computer Science Utrecht University www.netowork.me github.com/netogallo

What I do atm, is trying to compile using versions of an old haskell platform (like last year or something...)

Now cabal-bounds[1] really has the option '--haskell-platform' ;). So now you can call: cabal-bounds update --haskell-platform=2013.2.0.0 project.cabal or more convenient cabal-bounds update --haskell-platform=previous project.cabal Greetings, Daniel [1] https://github.com/dan-t/cabal-bounds

Hi Ernesto, What I do in that case it that I browse thru the old version number on hackage until I find one which match ~ the time of the platform I'm targeting, and I try to compile with it. That is the theory, and it can work not so bad if you do each you had a new dep... a pain if you have to do it retroactively though. Thanks Daniel! I'll definitely give it a try :-) On 4 September 2014 09:51, Ernesto Rodriguez wrote:

Hi Alois,

That certainly is an option. How well does it work with packages that are not part of the Haskell Platform. Do you simply try the oldest compatible versions of those packages?

Cheers

On Wed, Sep 3, 2014 at 8:51 AM, Alois Cochard wrote:

...

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" 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 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 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@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Ernesto Rodriguez

Masters Student Computer Science Utrecht University

www.netowork.me github.com/netogallo

-- *Λ\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard