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

[Magicloud Magiclouds]

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

[Ivan Lazar Miljenovic]

On 3 February 2012 16:54, Magicloud Magiclouds

<magicloud....@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.Mi...@gmail.com
IvanMiljenovic.wordpress.com

[Magicloud Magiclouds]

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.mi...@gmail.com> wrote:
> On 3 February 2012 16:54, Magicloud Magiclouds
> <magicloud....@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.Mi...@gmail.com
> IvanMiljenovic.wordpress.com

--
竹密岂妨流水过
山高哪阻野云飞

And for G+, please use magiclouds#gmail.com.

_______________________________________________

[Ivan Lazar Miljenovic]

On 3 February 2012 17:29, Magicloud Magiclouds

<magicloud....@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.

[Magicloud Magiclouds]

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

[Andres Löh]

Hi.

On Fri, Feb 3, 2012 at 7:44 AM, Ivan Lazar Miljenovic
<ivan.mi...@gmail.com> wrote:
> On 3 February 2012 17:29, Magicloud Magiclouds
> <magicloud....@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

[Magicloud Magiclouds]

Glad to hear that. I will checkout the trunk and try.

On Fri, Feb 3, 2012 at 6:20 PM, Andres Löh <andre...@googlemail.com> wrote:
> Hi.
>
> On Fri, Feb 3, 2012 at 7:44 AM, Ivan Lazar Miljenovic
> <ivan.mi...@gmail.com> wrote:
>> On 3 February 2012 17:29, Magicloud Magiclouds
>> <magicloud....@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.

_______________________________________________

[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
<magicloud....@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....@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

[Magicloud Magiclouds]

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

[Andres Löh]

> 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]

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

[Andres Löh]

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]

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.

--
竹密岂妨流水过
山高哪阻野云飞

And for G+, please use magiclouds#gmail.com.

_______________________________________________

[Magicloud Magiclouds]

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?

[Andres Löh]

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]

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 <andre...@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.

_______________________________________________

[Magicloud Magiclouds]

OK. I found cabal-src tool, which solved this perfect.