In EAPI 3, most commands and functions provided by the package
manager automatically call die if they fail. There's also a
new "nonfatal" function that can be used to suppress this
behaviour: by prefixing a function/command call with nonfatal,
the automatic die behaviour is suppressed during the executation
of that function/command.
The difficulty here is that it's not clear what nonfatal should
do to explicit die and assert calls. On the one hand, if
nonfatal does suppress these functions, then nonfatal can be
usefully used with eclass functions - silly hypothetical example:
# eclass
escons() {
scons "${@}" || die "scons failed"
}
# ebuild
nonfatal escons || do_something_else
On the other hand, it could be risky to change the behaviour of
existing functions like that:
do_foo() {
cd foo || die "cd failed"
# something that would be dangerous if run in some other directory
}
If called as "nonfatal do_foo" and the cd failed, do_foo
/wouldn't/ return a failure code - it would proceed with the rest
of its body and wreak all manner of havoc.
One way around this would be to add either an option to die to
explicitly tell it to respect nonfatal, or an alternative die
function. This would allow eclasses to choose to respect
nonfatal when it's safe to do so, but without changing existing
behaviour. The disadvantage of this is that it would require
changes to all eclass functions that could potentially use it,
plus the slight ugliness of making them handle older EAPIs as
well.
Another option would be to make die respect nonfatal by default,
and add an option that doesn't. This wouldn't require changes to
eclasses that want the nonfatal behaviour, but it would require
some care to make sure that it was used when necessary. A
potential advantage of this over the previous solution is that if
the "force" option is implemented with an environment variable,
it can be used regardless of EAPI - the previous example could be
changed to something like
do_foo() {
cd foo || DIE_FORCE=1 die "cd failed"
# something that would be dangerous if run in some other directory
}
Does anyone have any opinions on which of the four options (#1
make die respect nonfatal, #2 make die always die, #3 add a new
die variant that respects nonfatal, #4 make regular die respect
nonfatal, and add a new variant that doesn't) we should go with?
We should definitely get this resolved and agreed on before EAPI
3 is finalised.
manager automatically call die if they fail. There's also a
new "nonfatal" function that can be used to suppress this
behaviour: by prefixing a function/command call with nonfatal,
the automatic die behaviour is suppressed during the executation
of that function/command.
The difficulty here is that it's not clear what nonfatal should
do to explicit die and assert calls. On the one hand, if
nonfatal does suppress these functions, then nonfatal can be
usefully used with eclass functions - silly hypothetical example:
# eclass
escons() {
scons "${@}" || die "scons failed"
}
# ebuild
nonfatal escons || do_something_else
On the other hand, it could be risky to change the behaviour of
existing functions like that:
do_foo() {
cd foo || die "cd failed"
# something that would be dangerous if run in some other directory
}
If called as "nonfatal do_foo" and the cd failed, do_foo
/wouldn't/ return a failure code - it would proceed with the rest
of its body and wreak all manner of havoc.
One way around this would be to add either an option to die to
explicitly tell it to respect nonfatal, or an alternative die
function. This would allow eclasses to choose to respect
nonfatal when it's safe to do so, but without changing existing
behaviour. The disadvantage of this is that it would require
changes to all eclass functions that could potentially use it,
plus the slight ugliness of making them handle older EAPIs as
well.
Another option would be to make die respect nonfatal by default,
and add an option that doesn't. This wouldn't require changes to
eclasses that want the nonfatal behaviour, but it would require
some care to make sure that it was used when necessary. A
potential advantage of this over the previous solution is that if
the "force" option is implemented with an environment variable,
it can be used regardless of EAPI - the previous example could be
changed to something like
do_foo() {
cd foo || DIE_FORCE=1 die "cd failed"
# something that would be dangerous if run in some other directory
}
Does anyone have any opinions on which of the four options (#1
make die respect nonfatal, #2 make die always die, #3 add a new
die variant that respects nonfatal, #4 make regular die respect
nonfatal, and add a new variant that doesn't) we should go with?
We should definitely get this resolved and agreed on before EAPI
3 is finalised.
