1 |
In EAPI 3, most commands and functions provided by the package |
2 |
manager automatically call die if they fail. There's also a |
3 |
new "nonfatal" function that can be used to suppress this |
4 |
behaviour: by prefixing a function/command call with nonfatal, |
5 |
the automatic die behaviour is suppressed during the executation |
6 |
of that function/command. |
7 |
|
8 |
The difficulty here is that it's not clear what nonfatal should |
9 |
do to explicit die and assert calls. On the one hand, if |
10 |
nonfatal does suppress these functions, then nonfatal can be |
11 |
usefully used with eclass functions - silly hypothetical example: |
12 |
|
13 |
# eclass |
14 |
escons() { |
15 |
scons "${@}" || die "scons failed" |
16 |
} |
17 |
|
18 |
# ebuild |
19 |
nonfatal escons || do_something_else |
20 |
|
21 |
On the other hand, it could be risky to change the behaviour of |
22 |
existing functions like that: |
23 |
|
24 |
do_foo() { |
25 |
cd foo || die "cd failed" |
26 |
# something that would be dangerous if run in some other directory |
27 |
} |
28 |
|
29 |
If called as "nonfatal do_foo" and the cd failed, do_foo |
30 |
/wouldn't/ return a failure code - it would proceed with the rest |
31 |
of its body and wreak all manner of havoc. |
32 |
|
33 |
One way around this would be to add either an option to die to |
34 |
explicitly tell it to respect nonfatal, or an alternative die |
35 |
function. This would allow eclasses to choose to respect |
36 |
nonfatal when it's safe to do so, but without changing existing |
37 |
behaviour. The disadvantage of this is that it would require |
38 |
changes to all eclass functions that could potentially use it, |
39 |
plus the slight ugliness of making them handle older EAPIs as |
40 |
well. |
41 |
|
42 |
Another option would be to make die respect nonfatal by default, |
43 |
and add an option that doesn't. This wouldn't require changes to |
44 |
eclasses that want the nonfatal behaviour, but it would require |
45 |
some care to make sure that it was used when necessary. A |
46 |
potential advantage of this over the previous solution is that if |
47 |
the "force" option is implemented with an environment variable, |
48 |
it can be used regardless of EAPI - the previous example could be |
49 |
changed to something like |
50 |
|
51 |
do_foo() { |
52 |
cd foo || DIE_FORCE=1 die "cd failed" |
53 |
# something that would be dangerous if run in some other directory |
54 |
} |
55 |
|
56 |
Does anyone have any opinions on which of the four options (#1 |
57 |
make die respect nonfatal, #2 make die always die, #3 add a new |
58 |
die variant that respects nonfatal, #4 make regular die respect |
59 |
nonfatal, and add a new variant that doesn't) we should go with? |
60 |
We should definitely get this resolved and agreed on before EAPI |
61 |
3 is finalised. |