Support --logfile CLI option for all subcommands including login, rather than only build
#20251
Comments
sanmai-NL
added
the
kind/feature
|
a title is not typically complete enough of a feature request. i would recommend fixing this up to indicate why you want this, how it would be used, and why others would. |
In understand your concern. But have you read my post? Your questions are answered there. I can't speak for others. The motivation is the same as for the existing |
|
A friendly reminder that this issue had no activity for 30 days. |
|
Not stale. |
|
Interested in opening a PR to make this change? |
|
Yes, but this is beyond my Go proficiency (which is practically zero now). If some pointers can be left about the main modules to study, and the current logging architecture, it would make it more doable for me as well as others. |
Do you need more then this? |
|
|
I develop a few wrappers around Podman subcommands, and it occurred to me that some subcommands don't support the |
|
Well the only command that supports this is podman build, which is actually a vendor of buildah, which includes the option. |
|
That's an interesting historical background/context! I use the |
|
@edsantiago @Luap99 WDYT? |
|
I'm sorry. I can't see any possible justification for this. I even consider @sanmai-NL you were asked, within minutes of opening this issue, to justify your request. You declined. I will ask again: please justify your request, with full examples of how you see this being used and what you see this solving that |
|
I would be fine with hiding It seems like it might have been added for podman build on multi-streams. @flouthoc Do you recall why this flag was added? |
|
It does look useful in this combination: However, my limited imagination fails to find a case where this could apply to any other podman option. |
|
@edsantiago Is correct, buildah even implemented |
|
Note we already have the global I tend to agree with @edsantiago that io redirection is something callers should do, adding options for this to each and every application seems wrong in general. However given there is precedent for stdout I would not object adding a new option for stderr. |
|
@Luap99 For buildah's multi-arch builds |
|
I would vote no, just rely on the shell. |
|
As a user, here's my perspective again.
|
Hi @edsantiago, Please note that I didn't request adding I have justified the feature request in the OP. If you miss something, please point out what. I think the additional context you want is in #20251 (comment), by the way. |
|
In addition to #20251 (comment), I find that even when capturing stdout with |
|
Thank you, but we still seem to be stuck. You believe you have justified your request; I believe you have not. Could you please type two examples, fully spelled out, showing exact commands, exactly as they would be typed or written in a script, demonstrating this feature you're requesting? And then can you explain exactly how this would differ from command-line redirection? |
|
@edsantiago I observe that you're not responding to the specific content in comments, and come up with a requirement for me to re-explain something in a certain manner. Your colleagues seem to get the point and discuss various arguments around this issue. Again, you're somehow surmising that I accept nothing but podman build --logfile=podman-build-...log ...
podman login 2>podman-login-...log ...The preceding lines show the disparity between subcommands. This made no sense to me. Logging stderr to a file seems like a utility one would implement for all of Podman, and a convenience for users applicable to all of Podman, rather than just some subcommands. I proposed to support, for instance, this: podman build --logfile=podman-build-...log ...This difference in CLI interface gets more problematic when developing wrapper software. if __name__ == "__main__":
path_file_log = Path(
sanitize_filename(
f"podman-build.{timestamp}.log",
replacement_text="--",
),
)
run(
[ # noqa: S603
"podman",
"--log-level=debug",
f"--logfile={path_file_log}"
],
)if __name__ == "__main__":
path_file_log = Path(
sanitize_filename(
f"podman-login.{timestamp}.log",
replacement_text="--",
),
)
with path_file_log_stderr_push.open(
mode="x",
encoding="utf-8",
) as file_log_stderr_push:
run(
[ # noqa: S603
"podman",
"--log-level=debug",
],
stderr=file_log_stderr_push,
)Now what if I want to implement a class that can run Podman subcommands with a few generic parameters already set, like logging? Then I will have to special case for various subcommands, and find out which ones do support logging to a file as a convenience feature and which don't. And without the convenience functionality in the first place, I'll have to manage logging (files) as a caller. Later it turned out there's an Now, what of this information you didn't get from the previous posts? |
|
Thank you for your examples. I think they actually demonstrate the converse of what you're requesting: the correct solution is to use Python's (or any language's) facilities for capturing stdout/stderr. That's how redirection has worked in UNIX since the beginning. Tacking on (and maintaining) an unnecessary option is a burden. Would you want |
|
I think we're moving into highly subjective territory now. Managing logfiles is something many tools offer to take on. Why, if you think's out of scope in general? The pre-existence of Without addressing my points (e.g., around documentation), simply saying the caller should capture stderr and/or stdout does not fully address the issue I raised. I asked the fundamental question: why does this option exist, for some subcommand but not for others? |
|
I agree with Ed, we will not be adding additional options. |
|
We have answered the reason the buildah one exists. If the buildah team do not think it is necessary then they can deprecate it. |
|
@rhatdan I hope I won't have to file each and every point* separately now, for you and your team to actually capture the user input. |
I think you're taking a shortcut out of a discussion you don't want to continue. There is no argumentation on what makes the other subcommands so different. It's always easier to ignore comments. |
|
You are welcome to continue your conversation, but know we don't intend to implement it. |
github-actions
bot
added
the
locked - please file new issue/PR
Feature request description
See title.
Suggest potential solution
See title. My hope is that the logging logic can be factored out and reused for all of
podman. Even if perhaps, some subcommands tend to emit fewer log items.Have you considered any alternatives?
See title.
An alternative is to manually save stderr or stdout, depending on the type of log file (human vs. machine readable). But it makes no sense for one subcommand to have the option and the other not to.
Additional context
None.
The text was updated successfully, but these errors were encountered: