| 1 |
On 10/20/2012 11:16 AM, Zac Medico wrote: |
| 2 |
> On 10/20/2012 03:52 AM, Gregory M. Turner wrote: |
| 3 |
>> EAPI[0-3] conventions encourage the habit of writing ebuild code like |
| 4 |
>> |
| 5 |
>> invoke_fn || ... # handle error, probably by die()ing but maybe not |
| 6 |
>> |
| 7 |
>> But eclasses that auto-die violate this expectation and create a |
| 8 |
>> situation where ebuild authors must be mindful of whether a particular |
| 9 |
>> function is a helper-function or an eclass utility function to correctly |
| 10 |
>> anticipate whether auto-death will occur. |
| 11 |
>> |
| 12 |
>>should we really write new eclass code to behave this way as well? |
| 13 |
> |
| 14 |
> Yeah, I think we should. If the eclass function is doing something that |
| 15 |
> might result in an undesirable die, then it can try to avoid the die by |
| 16 |
> first doing a sanity check. For example, it can check that a given file |
| 17 |
> path exists before passing it to the helper, and skip calling the helper |
| 18 |
> if the file path doesn't exist. |
| 19 |
|
| 20 |
That seems reasonable -- in practice, I don't find myself needing to |
| 21 |
invoke helpers very much at all in eclasses, nor does it seem too |
| 22 |
terribly frequent in the existing eclasses (dodir is pretty common, but |
| 23 |
unlikely to fail unless something is seriously wrong anyhow). |
| 24 |
|
| 25 |
Would it be feasible to lift the >=EAPI4 restriction on nonfatal()? I |
| 26 |
guess the problem would be that old portage's wouldn't have it. |
| 27 |
|
| 28 |
Anyhow, given that eclasses can probably avoid auto-die() if they need |
| 29 |
to, this leaves the issue of nonfatal allowing die to return to |
| 30 |
callers... is there really any reason that die() needs to work this way? |
| 31 |
If helpers always used __helpers_die() instead of die(), then couldn't |
| 32 |
die() be changed to ignore PORTAGE_NONFATAL? |
| 33 |
|
| 34 |
It almost seems like the portage code was designed for nonfatal only to |
| 35 |
apply to helper invocations, and then the change to die() was added as |
| 36 |
an afterthought, to support the broader range of usages suggested |
| 37 |
(rather vaguely, I'd say) by the language in the PMS, ... yet somehow, |
| 38 |
the PMS ends up strongly suggesting -- I think most people would read |
| 39 |
the language as an explicit specification -- that ebuilds can rely on |
| 40 |
die() to terminate regardless of any usage of nonfatal. |
| 41 |
|
| 42 |
-gmt |
| 43 |
|
| 44 |
-gmt |
Archives