Project

General

Profile

Feature #13554

Improved context information upon version conflict

Added by Kyle Knoepfel almost 3 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
08/15/2016
Due date:
% Done:

0%

Estimated time:
Spent time:
Experiment:
-
Duration:

Description

Please see issue #13530.

We would like more context information whenever a version collision occurs between products--namely, what is the parent product setting up the product in question, and what is the product chain leading to the top of the stack that contains the conflict.


Related issues

Related to mrb - Bug #13530: Conflict messages from UPS setup are less than helpfulClosed2016-08-12

History

#1 Updated by Lynn Garren almost 3 years ago

  • Related to Bug #13530: Conflict messages from UPS setup are less than helpful added

#2 Updated by Marc Mengel almost 3 years ago

Kyle,

You can get all of this info by doing a "ups depend" with the same options
as the setup. So in a script you could do:

setup $args || ups depend $args

A shorter answer is often wrong; as there may be multiple dependencies conflicting. But the long answer is also obfuscating, as it's huge:

<dunegpvm01>$ ups depend -B dunetpc v06_02_00 -q debug:e10 | wc -l
2618

whereas the pruned listing (each package once) is:

<dunegpvm01>$ ups depend dunetpc v06_02_00 -q debug:e10 | wc -l
73

#3 Updated by Kyle Knoepfel almost 3 years ago

Hi Marc, yes we knew about the ups depend option. But your statement about the long and short answers being obfuscating and often wrong, respectively, illustrate the point. For example, with the dunetpc example, having a print out that said something like the following would be beneficial:

ERROR: Conflicting versions when setting up product: art
========================================================
dunetpc v06_02_00 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/dune -q debug:e10
|__larsoft v06_02_00 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/larsoft -q debug:e10
|  |__lareventdisplay v06_00_03 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/larsoft -q debug:e10
|     |__larsim v06_01_01 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/larsoft -q debug:e10
|        |__larevt v06_00_02 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/larsoft -q debug:e10
|           |__lardata v06_01_00 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/larsoft -q debug:e10
|              |__larcore v06_00_01 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/larsoft -q debug:e10
|                 |__art v2_03_00 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/larsoft -q debug:e10:nu
|  ...
| 
|__lbne_raw_data v1_04_00 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/dune -q debug:e10:nu:s36
   |__artdaq_core v1_05_01 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/larsoft -q debug:e10:nu:s36
      |__art v2_00_03 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/larsoft -q debug:e10:nu

where only the relevant portions of the product tree are printed: namely, the product branch showing that art v2_03_00 is set up first, and the other product branch showing that an attempt to set up art v2_00_03 later fails.

Could such a printout be produced?

#4 Updated by Marc Mengel almost 3 years ago

Well, I did some looking at the code... Printing what it is we're setting up
when we get the conflict is fairly easy, and is checked in already.

Setting up the depend code to prune it for the paths to a given dependency is going to require a bit of thinking...

The print loop basically gets handed a linked list of dependencies with depths; so you would need to go through and find an instance of the desired package, then go backwards until you get to the last start point and prune other branches, then scan forward for the package again... and at the end, prune everything past the last match, and then print the resulting pruned list... Or possibly it would just build a new pruned list, and leave the old one alone; otherwise the memory management might get a bit silly...

... so the pruning could work by keeping an array of max latest list position pointers by depth, and a flag of whether its been copied to the output, and when you hit the desired package, you add the unadded items in the depth array to the output list and flag them, you always clear the corresponding flag when you update the array item...

Oh, and it would in this case need to print to stderr and not stdout; 'cause stdout is going to the setup file, so that factored out print code would need to take a file handle and use it throughout.

So it would need a rework of the ups depend code; probably factoring it into 3 pieces so the regular depend code and the pruned-dependency-for-errors code could share the parts. Since I'm scheduled for about .01FTE on ups/upd, it may be a little while 'till I get around to actually implementing it and testing it.

... Oh, and we'd probably need a new global (shudder) to hold the package that we hit the conflict on, so we know what to do the pruned dependency for...

#5 Updated by Kyle Knoepfel almost 3 years ago

Marc, thanks for taking a look at this. If printing what is currently being set-up is fairly easy, then perhaps the following is a decent compromise:

ERROR: Conflicting versions when setting up product: art
========================================================
dunetpc v06_02_00 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/dune -q debug:e10
|__lbne_raw_data v1_04_00 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/dune -q debug:e10:nu:s36
   |__artdaq_core v1_05_01 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/larsoft -q debug:e10:nu:s36
      |__art v2_00_03 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/larsoft -q debug:e10:nu

Version defined earlier in setup: art v2_03_00 ...

In other words, just print out the product-branch where the conflict is occurring. Is that reasonable?

#6 Updated by Marc Mengel almost 3 years ago

Well, my earlier point was, the caller can do that now by doing

setup $args || ups depend $args

(i.e. do a ups depend if the setup fails).

#7 Updated by Marc Mengel about 2 years ago

  • Status changed from New to Closed


Also available in: Atom PDF