Re: [Haskell-cafe] Again, version conflicting problem with cabal-install

Jason Dagit

3 Feb 2012 3 Feb '12

10:48 a.m.

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 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 wrote:

...
On Thu, Feb 2, 2012 at 9:54 PM, Magicloud Magiclouds 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.

Show replies by date

Magicloud Magiclouds

3 Feb 3 Feb

11:15 a.m.

New subject: 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 :

...

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 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 wrote:

...
On Thu, Feb 2, 2012 at 9:54 PM, Magicloud Magiclouds 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.

Andres Löh

11:22 a.m.

New subject: 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

Felipe Almeida Lessa

11:31 a.m.

New subject: Again, version conflicting problem with cabal-install

On Fri, Feb 3, 2012 at 2:22 PM, Andres Löh 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.

Andres Löh

11:36 a.m.

New subject: 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

Magicloud Magiclouds

2 May 2 May

2:47 a.m.

New subject: 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 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.

Magicloud Magiclouds

19 Jun 19 Jun

5:39 a.m.

New subject: 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 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 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.

Andres Löh

5:50 a.m.

New subject: 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

Magicloud Magiclouds

9:22 p.m.

New subject: 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 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.

Magicloud Magiclouds

20 Jun 20 Jun

2:23 a.m.

New subject: 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 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 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.

4717

Age (days ago)

4855

Last active (days ago)

List overview

Download

9 comments

4 participants

participants (4)

Andres Löh
Felipe Almeida Lessa
Jason Dagit
Magicloud Magiclouds