| Summary: | [Future EAPI] provide an exherbo edo-like helper | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | David Seifert <soap> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | esigra, sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
|
Description
David Seifert
2020-09-26 22:22:17 UTC
What would be failure behaviour? Die if the command fails, unless run under nonfatal? My main concern is that this would (under a different name) reintroduce the "try" syntax ... https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-editors/emacs/emacs-20.7.ebuild?hideattic=0&revision=1.4&view=markup#l34 https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/bin/ebuild.sh?revision=1.1&view=markup#l85 ... which was abolished in 2001 for good reason: https://archives.gentoo.org/gentoo-dev/message/e20409cb1cf264f5c7a24bdf060ea060 So, I find this one rather problematic. If the goal is to have more verbose logs, then maybe have the package manager enable "set -v" or "set -x" when executing a phase function? (In reply to Ulrich Müller from comment #1) > What would be failure behaviour? Die if the command fails, unless run under > nonfatal? > > My main concern is that this would (under a different name) reintroduce the > "try" syntax ... > > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-editors/emacs/ > emacs-20.7.ebuild?hideattic=0&revision=1.4&view=markup#l34 > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/bin/ebuild. > sh?revision=1.1&view=markup#l85 > > ... which was abolished in 2001 for good reason: > > https://archives.gentoo.org/gentoo-dev/message/ > e20409cb1cf264f5c7a24bdf060ea060 > > So, I find this one rather problematic. If the goal is to have more verbose > logs, then maybe have the package manager enable "set -v" or "set -x" when > executing a phase function? Exherbo makes it "die unless under nonfatal". All the cases of this idiom in all ebuilds I found were fatal (or forgot to make it fatal as a matter of QA, they didn't rely on "maybe fatal and I will recover" patterns), so I think making it unconditionally fatal is absolutely fine. I don't really see a use case for making this non-fatal anyways. > So, I find this one rather problematic. If the goal is to have more verbose
> logs, then maybe have the package manager enable "set -v" or "set -x" when
> executing a phase function?
I think both set -v -x are too broad, and they'll massively flood logs.
I believe it is conceptionally wrong to have to put a wrapper function in front of every command, just to enable additional verbosity. Also it would suffer from all the issues mentioned in the mailing list post cited above. Portage already outputs the command as part of the "die" call stack, so the interesting case when a command fails is already covered. (In reply to David Seifert from comment #2) > Exherbo makes it "die unless under nonfatal". All the cases of this idiom in > all ebuilds I found were fatal (or forgot to make it fatal as a matter of > QA, they didn't rely on "maybe fatal and I will recover" patterns), so I > think making it unconditionally fatal is absolutely fine. I don't really see > a use case for making this non-fatal anyways. It would lose the possibility to specify a "die" command with an explicit error message. I'd really like us to revisit this. It's come up again in the light of some of the ebegin/eend bug fixes (bug 835823, bug 835824). Came up in #gentoo-dev (edited for brevity): """ [15:26:24] <@floppym> soap: Is "edo" a thing? I guess you're saying we should really have a common helper function for this. [16:17:20] <@ulm> floppym: we had that before, it was called "try" [16:17:49] <@ulm> it was replaced by "|| die" in 2001: https://archives.gentoo.org/gentoo-dev/message/e20409cb1cf264f5c7a24bdf060ea060 [16:25:55] <@Flow> what if edo doesn't automatically die? sure that would be out of line with modern EAPI helpers… [16:30:32] <@ulm> Flow: we'd still have most of the problems, e.g. with redirection and with pipes [16:40:30] <@ulm> would be trivial to introduce such a thing with an eclass, then we could get more easily rid of it or change it, if it turns out to be a mistake, much harder if it's part of an EAPI [16:48:16] <@Flow> so edo and edod (edo or die) in an eclass? sounds like something we should try [16:50:10] <@ulm> I'd rather call it something else though, like debug-print-and-exec [16:51:07] <@Flow> hmm, I was under the impression that a short name would be desirable, but I've no idea how often this pattern appears [16:53:46] <@floppym> ulm: Long helper names are obnoxious to read. [16:56:45] <@ulm> edebug? [16:57:04] <@Flow> what do you debug? [16:57:37] <@ulm> the command? or at least that's stated as the goal in that bug [16:58:23] <@Flow> maybe we are talking about different things here, in case of java-utils eclass it's the invocation of javac that does not output anything while it is compiling [16:58:43] <@ulm> I was talking about "edo" suggested in bug 744880 [16:58:44] <@ulm> "echo commands for debuggability" [16:58:46] <@Flow> so you want do know at least the command that is currently running, by having it appear in the log, it sure can be used to post morten analysis or "debuggability" [16:59:25] <@floppym> I don't think "debuggability" is the only reason to echo the command. It also tells users what the thing is doing. [16:59:30] <@Flow> right, so maybe, eexec, but then again, its too close to exec, ecall? [17:00:17] <@ulm> Flow: if it's invoked from an eclass, wouldn't it be trivial to sandwich it between ebegin/eend? why would you need an additional helper? [17:00:51] <@floppym> Who brought up ebegin/eend? [17:01:46] <@Flow> nobody, but it would mabye be nice to have an ebegin variant that takes the command to execute as argument, calls ebegin with it can executes it [17:02:13] <@ulm> floppym: sounds natural if you invoke some command that may output some error messages? [17:02:18] <@floppym> Anyway, either edo or ecall sounds ok to me. [17:02:20] <@Flow> still, one should probably be able to do the "print command string and execute command" dance without using ebegin [17:02:54] <@Flow> ulm: err, no, if the command outputs *anything* then ebegin wouldn't be ideal I think [17:03:19] <@Flow> doesn't eend print something on the right side of the console? that would then be displaced if the command outputs something [17:03:55] <@ulm> <@Flow> in case of java-utils eclass it's the invocation of javac that does not output anything while it is compiling [17:04:31] <@Flow> yes, in this case ebegin is fine, but I hope that commands that output a little bit while doing their work are more common :) [17:04:37] <@ulm> ebegin "running javac"; javac; eend $? || die "javac failed" [17:07:33] <@floppym> I would say ebegin/eend is useful when you have a long-running command that normally generates no output, and you know the command's arguments ahead of time. edo/ecall is more useful when the arguments for the command may vary, and you want to see them in the log. [17:11:43] <@ulm> somthing like this? [17:11:45] <@ulm> edo() { eshopts_push; set -vx; "$@"; local status=$?; eshopts_pop; [[ ${status} -eq 0 ]] || die -n "$@ failed"; return ${status}; } [17:14:16] ulm still thinks that we should call it "try" :) [17:19:02] <@Flow> ulm: looks good :) [17:23:27] <@ulm> any idea how many ebuilds would need such a thing? none of mine, I think [17:25:22] <@Flow> I think java-utils would potentially want something like [17:25:28] <@Flow> edo-begin-end() { ebegin "$@"; "$@"; local status=$?; eend ${status} return ${status} } [17:26:47] <@ulm> no need for a variable, eend passes the status through [17:26:55] <@ulm> edo-begin-end() { ebegin "$@"; "$@"; eend $?; return $?; } """ The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=18109919b4f983da20bf9656b4f819fe3802d904 commit 18109919b4f983da20bf9656b4f819fe3802d904 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-04-16 06:16:20 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-04-18 17:43:47 +0000 edo.eclass: add new eclass Bug: https://bugs.gentoo.org/744880 Signed-off-by: Sam James <sam@gentoo.org> eclass/edo.eclass | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) |
