Re: [gentoo-dev] EAPI 3 and "nonfatal die"

[Arfrever Frehtes Taifersar Arahesis]

2009-08-21 22:56:41 David Leverton napisał(a):
> 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?

I think that 'DIE_FORCE=1 die "${die_message}"' (which was invented by me) would be the
best option. It will allow to use nonfatal() with eclass functions with the smallest
number of required changes in eclasses.

I would like to also notice that (not yet approved by Council) definition of nonfatal()
in PMS was recently drastically changed without proper discussion with developers of
other package managers. [1] was sent about 20 minutes after discussion about nonfatal()
started in #gentoo-portage in about 2009-08-06 19:45 UTC.
(I'm attaching IRC log from #gentoo-portage (in UTC+02 timezone).)
I think that such drastic changes should be first discussed on gentoo-dev mailing list.

[1] http://archives.gentoo.org/gentoo-pms/msg_5ae501394eaeff148cfc349f84d960c9.xml

-- 
Arfrever Frehtes Taifersar Arahesis