How to find a conflicting package?

[Francois Lord]

Hi,

What is the official workflow to isolate conflicting packages? rez-env
tells me there is a conflict, but doesn't give me much information

The context failed to resolve:
The following package conflicts occurred: (platform-linux <--!-->
platform-osx)

I tried this:

rez-env [package list] -o file.rxt
rez-context -g file.rxt

but the offending package doesn't show up in the graph. It shows a
conflict where there is no conflict.

I had a list of 10 packages and had to remove them one by one to figure
out which one was causing the problem. It was a package version that had
been released only for osx variant.

I suppose there is a better way to do it?

Thanks

F

[Allan Johns]

Hi,

No this is the right way to do it. Rez doesn't give more info on the commandline because it is far too hard to decipher, it's much more comprehensible by looking at the graph. This is just the nature of the problem - to show the relevant info in text would be to show something like "x-1 <--> x-2 because y-1.5 required x-1 and z-1.3 required x-2, and z-1.3 was required because foo-6.5 required it, which was resolved because... etc...". In very early rez versions this was actually the only way you could see this info and it's like reading the matrix. You can still see it this way though, if you're keen - use the verbose option, you'll probably want -vvv.

Your case sounds suspiciously like one we found recently that actually exposes a bug in the conflict graph generation code, so you may have hit that. It's pretty rare, and I want to fix it next time I delve into the solver code.

A

F


--
You received this message because you are subscribed to the Google Groups "rez-config" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rez-config+unsubscribe@googlegroups.com.
To post to this group, send email to rez-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/rez-config.
For more options, visit https://groups.google.com/d/optout.

[Francois Lord]

Well, it doesn't look like a very rare bug. I haven't been able to find conflicts by using the graph yet. All conflicts cases I had were resolved by removing packages one by one from the rez-env list, which is a bit annoying to say the least.

For example, I got this conflict this morning. In the end, the real conflict was totally unrelated to alshaders.

To unsubscribe from this group and stop receiving emails from it, send an email to rez-config+...@googlegroups.com.

[Allan Johns]

You must have hit on some situation that's getting you these odd graphs fairly reliably I guess, I haven't seen an issue like this for a long time.

It's very difficult to fix these cases as I need a repro involving all the packages that were touched during the solve. More and more I see the need to add debugging support to rez so that this info can get dumped to some form of (probably JSON) archive, that itself is a valid package repository. That way you could just mail it to me and I'd have all the info I need.

Wrt the on-by-one removal of packages to track down an issue, someone else has pointed out that this is a common thing to do, and that it'd be helpful to have a rez-env mode which does it for you (roughly analogous to git bisect I suppose). I think this would be worth doing.

In any case yes this looks like a bug in the graph generation.

A

[Fede Naum]

Hi Francois, Alan,

One thing that has helped me several times when the default graph does not show me clearly the conflict is to set the prune_failed_graph=False, before trying the resolve, then the resulting graph has more packages to help you understand the root cause of the problem.  I'm actually quite tempted to set it to False by default as we have more than ~1000 rez packages and many have some non-mutually exclusive variants.

Other 'technique' you can use to narrow down the culprit package, is to pass -t TIMESTAMP to rez env in a sort of bisect mode, so packages released before that date are not taken into account. then when you have one that rez env that is working and the other not, you can see the packages that were released between this 2 TIMESTAMPS. or pick a date in the middle again. Does it make sense?

Hope this helps!!

Fede

To unsubscribe from this group and stop receiving emails from it, send an email to rez-config+...@googlegroups.com.

To post to this group, send email to rez-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/rez-config.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "rez-config" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rez-config+...@googlegroups.com.

To post to this group, send email to rez-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/rez-config.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "rez-config" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rez-config+...@googlegroups.com.

[Allan Johns]

Hey Fede,

Yeah in terms of this bisect-type functionality, bisecting both on the packages list (whittling down that list) and on time, are both good.. axis..? for bisection. I would aim to support both.

A

To unsubscribe from this group and stop receiving emails from it, send an email to rez-config+unsubscribe@googlegroups.com.