Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
OK. I found cabal-src tool, which solved this perfect. On Wed, Jun 20, 2012 at 9:22 AM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, The names here were just placeholder. And I just found out the reason. Hackage magicloud is local (not from hackage.haskell.org), there is no its information in cabal INDEX (I assumed so). But this raised another question, how to reference a local hackage in .cabal. So the solver could use the dependencies originally defined but not the binary compiled (which dependencies are fixed)? On Tue, Jun 19, 2012 at 5:50 PM, Andres Löh andres.l...@googlemail.com wrote: Hi. Hackage A depends on magicloud (any) and container (0.4.0.0), and hackage magicloud depends on container (any). Now I've installed magicloud, using container 0.5.0.0. Then I failed to install A, with any solver. So the solvers are using the status that is installed, not the definitions from original hackages? Could you please provide me with something I can reproduce? I'm not sure what you mean by A or magicloud. Are you saying they have no further dependencies except for the one on container? If you could just state which concrete packages have caused the problem, it'd probably be easier. The trace output of the modular solver with -v3 would also help (send it to me personally if it's too long). Thanks. Andres -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
And today I met another situation, which I think solvable by computer. Hackage A depends on magicloud (any) and container (0.4.0.0), and hackage magicloud depends on container (any). Now I've installed magicloud, using container 0.5.0.0. Then I failed to install A, with any solver. So the solvers are using the status that is installed, not the definitions from original hackages? On Wed, May 2, 2012 at 2:47 PM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, long time no see. I am using cabal-install-0.15.0. And the new solver. It sure solves some problem. Thanks for the work. Well, on the other hand, there still are hackages that I just have no idea how the author make it (probably not up-to-date hackage database). After human-solver checking, these hackages are not be able to build at all under certain conditions. So, I am voting on the force-allow flag. On Sat, Feb 4, 2012 at 12:36 AM, Andres Löh andres.l...@googlemail.com wrote: Hi. --force-allow=foo-1.3 with the semantics that all dependencies on foo will be changed to allow foo-1.3 to be chosen. Would that be ok? Other suggestions? Can't this be integrated with the current --constraint flag? It could be, but ... If the constraint is able to be satisfied without unrestricting any bounds, fine. Otherwise, unrestrict any bounds on that constraint. What would be the drawbacks? ... it shouldn't happen automatically. There are perfectly valid and safe reasons to use --constraint, whereas this new feature is inherently unsafe. But allowing general constraint syntax and calling the flag something with constraint in it is perhaps a good idea. An advantage is being able to specify --constraint='foo = 1.3' to get foo-1.3.7.2 instead of having to find out exactly which version you want. And if you already know what you want, you may always say --constraint='foo == 1.3.7.2'. Yes. Looking forward to the new solver! =) I need testers and feedback. You can already use it. It's in the cabal-install development version, and can be enabled by saying --solver=modular on the command line. Cheers, Andres -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
Hi. Hackage A depends on magicloud (any) and container (0.4.0.0), and hackage magicloud depends on container (any). Now I've installed magicloud, using container 0.5.0.0. Then I failed to install A, with any solver. So the solvers are using the status that is installed, not the definitions from original hackages? Could you please provide me with something I can reproduce? I'm not sure what you mean by A or magicloud. Are you saying they have no further dependencies except for the one on container? If you could just state which concrete packages have caused the problem, it'd probably be easier. The trace output of the modular solver with -v3 would also help (send it to me personally if it's too long). Thanks. Andres ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
Hi, The names here were just placeholder. And I just found out the reason. Hackage magicloud is local (not from hackage.haskell.org), there is no its information in cabal INDEX (I assumed so). But this raised another question, how to reference a local hackage in .cabal. So the solver could use the dependencies originally defined but not the binary compiled (which dependencies are fixed)? On Tue, Jun 19, 2012 at 5:50 PM, Andres Löh andres.l...@googlemail.com wrote: Hi. Hackage A depends on magicloud (any) and container (0.4.0.0), and hackage magicloud depends on container (any). Now I've installed magicloud, using container 0.5.0.0. Then I failed to install A, with any solver. So the solvers are using the status that is installed, not the definitions from original hackages? Could you please provide me with something I can reproduce? I'm not sure what you mean by A or magicloud. Are you saying they have no further dependencies except for the one on container? If you could just state which concrete packages have caused the problem, it'd probably be easier. The trace output of the modular solver with -v3 would also help (send it to me personally if it's too long). Thanks. Andres -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
Hi, long time no see. I am using cabal-install-0.15.0. And the new solver. It sure solves some problem. Thanks for the work. Well, on the other hand, there still are hackages that I just have no idea how the author make it (probably not up-to-date hackage database). After human-solver checking, these hackages are not be able to build at all under certain conditions. So, I am voting on the force-allow flag. On Sat, Feb 4, 2012 at 12:36 AM, Andres Löh andres.l...@googlemail.com wrote: Hi. --force-allow=foo-1.3 with the semantics that all dependencies on foo will be changed to allow foo-1.3 to be chosen. Would that be ok? Other suggestions? Can't this be integrated with the current --constraint flag? It could be, but ... If the constraint is able to be satisfied without unrestricting any bounds, fine. Otherwise, unrestrict any bounds on that constraint. What would be the drawbacks? ... it shouldn't happen automatically. There are perfectly valid and safe reasons to use --constraint, whereas this new feature is inherently unsafe. But allowing general constraint syntax and calling the flag something with constraint in it is perhaps a good idea. An advantage is being able to specify --constraint='foo = 1.3' to get foo-1.3.7.2 instead of having to find out exactly which version you want. And if you already know what you want, you may always say --constraint='foo == 1.3.7.2'. Yes. Looking forward to the new solver! =) I need testers and feedback. You can already use it. It's in the cabal-install development version, and can be enabled by saying --solver=modular on the command line. Cheers, Andres -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
Yes and probably a runtime crash even if passed the compile. But I think if we let it stay the way it is, the hackage empire would be down any minute. All big hackages are depending on many other hackages by many other authors. So big chance that the top hackage cannot be installed (like I suffered recently). Maybe I should crack my cabal source to add an argument to ignore version checking On Fri, Feb 3, 2012 at 2:44 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 3 February 2012 17:29, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Thank you. The document does say it more clearly than me. But still, currently, ghc only gives me one option: cannot be built. How about giving me another one: throw away the version information of D when building A. So when A uses types in D with B and C, it might work. Just the risk is on me now. It is not perfect, but would work sometimes But not always. We'd then have other errors: why isn't this build working? Types can be re-exported, class instances are implicitly imported/exported, etc. On Fri, Feb 3, 2012 at 2:04 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 3 February 2012 16:54, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hello, As I recalled, ghc works in staticly link mode. So after one library is compiled, all its build dependencies are useless. Lost, changed, wheresoever, it does not matter. Then why the problem of version conflicting exists? By version conflicting I mean like following. This way, A is not installable by cabal. A needs B 0.1 A needs C 0.1 B needs C0.2 See the Dreaded Diamond Dependency Problem: http://www.well-typed.com/blog/9 -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
Hi. On Fri, Feb 3, 2012 at 7:44 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 3 February 2012 17:29, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Thank you. The document does say it more clearly than me. But still, currently, ghc only gives me one option: cannot be built. How about giving me another one: throw away the version information of D when building A. So when A uses types in D with B and C, it might work. Just the risk is on me now. It is not perfect, but would work sometimes But not always. We'd then have other errors: why isn't this build working? Types can be re-exported, class instances are implicitly imported/exported, etc. It's a valid complaint, and there's ongoing work to fix some of these issues. In the meantime, the development version of cabal-install, in particular the new modular solver, can deal with a few situations that can't be resolved by older cabal-install versions. I can't promise it will help here. But I'm still interested in feedback. Cheers, Andres ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
Glad to hear that. I will checkout the trunk and try. On Fri, Feb 3, 2012 at 6:20 PM, Andres Löh andres.l...@googlemail.com wrote: Hi. On Fri, Feb 3, 2012 at 7:44 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 3 February 2012 17:29, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Thank you. The document does say it more clearly than me. But still, currently, ghc only gives me one option: cannot be built. How about giving me another one: throw away the version information of D when building A. So when A uses types in D with B and C, it might work. Just the risk is on me now. It is not perfect, but would work sometimes But not always. We'd then have other errors: why isn't this build working? Types can be re-exported, class instances are implicitly imported/exported, etc. It's a valid complaint, and there's ongoing work to fix some of these issues. In the meantime, the development version of cabal-install, in particular the new modular solver, can deal with a few situations that can't be resolved by older cabal-install versions. I can't promise it will help here. But I'm still interested in feedback. Cheers, Andres -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
In my experience the diamond of death is typically because: * You install package A that uses C-0.1 * Someone uploads C-0.2 to hackage * Later you 'cabal update', this does not rebuild A to use C-0.2, even though it could. * You install package B that uses C, and cabal builds it with C-0.2 * Now you want to build D that uses A and B, but A requires C-0.1 and B requires C-0.2, even though they could be rebuilt to use the same C. Typically, the constraints on A, B, and D would all accept the same version of C. Except that when they were compiled separately and C changed between building A and B, then the compiled versions become fixed on C-0.1 and C-0.2. It's true that it won't solve it in all cases, but in my experience using cabal-dev made the problem go away. I hope that clarifies. Jason On Fri, Feb 3, 2012 at 7:33 AM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Well, cabal-dev could not resolve the conflict of the diamond. Because the conflict is depending different version at the SAME time. On Fri, Feb 3, 2012 at 9:20 PM, Jason Dagit dag...@gmail.com wrote: On Thu, Feb 2, 2012 at 9:54 PM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hello, As I recalled, ghc works in staticly link mode. So after one library is compiled, all its build dependencies are useless. Lost, changed, wheresoever, it does not matter. Then why the problem of version conflicting exists? I'm not sure, but for me this problem has gone away by using cabal-dev to build everything. Jason -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
I think this could be gone with cabal-dev only if A has a new version or the compiled one that could use C-0.2 or caba-dev could ignore the version constraint. So it is kind of an old binary problem. It could also be resolved by reinstall A to use C-0.2 with cabal-install. The problem I met is that, A uses B and C-0.2, and B uses C-0.1. Both dependencies to C were strict. I had not gotten any B or C installed. Now I just started to install A. It would fail. In fact, there was a chance that I just modified B.cabal to use C-0.2 and all things done. But there also was a risk of unable to compile or even runtime crash. I am just wanting an option (ignore versions) to take that risk in develop environment. 2012/2/3 Jason Dagit dag...@gmail.com: In my experience the diamond of death is typically because: * You install package A that uses C-0.1 * Someone uploads C-0.2 to hackage * Later you 'cabal update', this does not rebuild A to use C-0.2, even though it could. * You install package B that uses C, and cabal builds it with C-0.2 * Now you want to build D that uses A and B, but A requires C-0.1 and B requires C-0.2, even though they could be rebuilt to use the same C. Typically, the constraints on A, B, and D would all accept the same version of C. Except that when they were compiled separately and C changed between building A and B, then the compiled versions become fixed on C-0.1 and C-0.2. It's true that it won't solve it in all cases, but in my experience using cabal-dev made the problem go away. I hope that clarifies. Jason On Fri, Feb 3, 2012 at 7:33 AM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Well, cabal-dev could not resolve the conflict of the diamond. Because the conflict is depending different version at the SAME time. On Fri, Feb 3, 2012 at 9:20 PM, Jason Dagit dag...@gmail.com wrote: On Thu, Feb 2, 2012 at 9:54 PM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hello, As I recalled, ghc works in staticly link mode. So after one library is compiled, all its build dependencies are useless. Lost, changed, wheresoever, it does not matter. Then why the problem of version conflicting exists? I'm not sure, but for me this problem has gone away by using cabal-dev to build everything. Jason -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
I am just wanting an option (ignore versions) to take that risk in develop environment. A controlled way of ignoring version constraints (mainly upper bounds, actually) is certainly on my TODO list for the new solver. The main issue to work out is a good way how to control the disabled bounds via the command line, because you usually don't want to ignore all of them. Currently, my UI-preference is a flag --force-allow=foo-1.3 with the semantics that all dependencies on foo will be changed to allow foo-1.3 to be chosen. Would that be ok? Other suggestions? Cheers, Andres ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
On Fri, Feb 3, 2012 at 2:22 PM, Andres Löh andres.l...@googlemail.com wrote: A controlled way of ignoring version constraints (mainly upper bounds, actually) is certainly on my TODO list for the new solver. The main issue to work out is a good way how to control the disabled bounds via the command line, because you usually don't want to ignore all of them. Currently, my UI-preference is a flag --force-allow=foo-1.3 with the semantics that all dependencies on foo will be changed to allow foo-1.3 to be chosen. Would that be ok? Other suggestions? Can't this be integrated with the current --constraint flag? If the constraint is able to be satisfied without unrestricting any bounds, fine. Otherwise, unrestrict any bounds on that constraint. What would be the drawbacks? An advantage is being able to specify --constraint='foo = 1.3' to get foo-1.3.7.2 instead of having to find out exactly which version you want. And if you already know what you want, you may always say --constraint='foo == 1.3.7.2'. Looking forward to the new solver! =) Cheers! -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
Hi. --force-allow=foo-1.3 with the semantics that all dependencies on foo will be changed to allow foo-1.3 to be chosen. Would that be ok? Other suggestions? Can't this be integrated with the current --constraint flag? It could be, but ... If the constraint is able to be satisfied without unrestricting any bounds, fine. Otherwise, unrestrict any bounds on that constraint. What would be the drawbacks? ... it shouldn't happen automatically. There are perfectly valid and safe reasons to use --constraint, whereas this new feature is inherently unsafe. But allowing general constraint syntax and calling the flag something with constraint in it is perhaps a good idea. An advantage is being able to specify --constraint='foo = 1.3' to get foo-1.3.7.2 instead of having to find out exactly which version you want. And if you already know what you want, you may always say --constraint='foo == 1.3.7.2'. Yes. Looking forward to the new solver! =) I need testers and feedback. You can already use it. It's in the cabal-install development version, and can be enabled by saying --solver=modular on the command line. Cheers, Andres ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Again, version conflicting problem with cabal-install
Hello, As I recalled, ghc works in staticly link mode. So after one library is compiled, all its build dependencies are useless. Lost, changed, wheresoever, it does not matter. Then why the problem of version conflicting exists? By version conflicting I mean like following. This way, A is not installable by cabal. A needs B 0.1 A needs C 0.1 B needs C0.2 -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
On 3 February 2012 16:54, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hello, As I recalled, ghc works in staticly link mode. So after one library is compiled, all its build dependencies are useless. Lost, changed, wheresoever, it does not matter. Then why the problem of version conflicting exists? By version conflicting I mean like following. This way, A is not installable by cabal. A needs B 0.1 A needs C 0.1 B needs C0.2 See the Dreaded Diamond Dependency Problem: http://www.well-typed.com/blog/9 -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
Thank you. The document does say it more clearly than me. But still, currently, ghc only gives me one option: cannot be built. How about giving me another one: throw away the version information of D when building A. So when A uses types in D with B and C, it might work. Just the risk is on me now. It is not perfect, but would work sometimes On Fri, Feb 3, 2012 at 2:04 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 3 February 2012 16:54, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hello, As I recalled, ghc works in staticly link mode. So after one library is compiled, all its build dependencies are useless. Lost, changed, wheresoever, it does not matter. Then why the problem of version conflicting exists? By version conflicting I mean like following. This way, A is not installable by cabal. A needs B 0.1 A needs C 0.1 B needs C0.2 See the Dreaded Diamond Dependency Problem: http://www.well-typed.com/blog/9 -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
On 3 February 2012 17:29, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Thank you. The document does say it more clearly than me. But still, currently, ghc only gives me one option: cannot be built. How about giving me another one: throw away the version information of D when building A. So when A uses types in D with B and C, it might work. Just the risk is on me now. It is not perfect, but would work sometimes But not always. We'd then have other errors: why isn't this build working? Types can be re-exported, class instances are implicitly imported/exported, etc. On Fri, Feb 3, 2012 at 2:04 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 3 February 2012 16:54, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hello, As I recalled, ghc works in staticly link mode. So after one library is compiled, all its build dependencies are useless. Lost, changed, wheresoever, it does not matter. Then why the problem of version conflicting exists? By version conflicting I mean like following. This way, A is not installable by cabal. A needs B 0.1 A needs C 0.1 B needs C0.2 See the Dreaded Diamond Dependency Problem: http://www.well-typed.com/blog/9 -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
