From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A14B71F4C4 for ; Fri, 8 Nov 2024 09:01:11 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=QtbtVT8W; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=gTXDkaXh; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1731056439; bh=lqPvDOkY1JsIsBleIEtpdx1vXxzgquCQ+PuZVFLZhCY=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=QtbtVT8WHoJUJV+9YWKStHJN24f0gEKheNfd1+rsax58SgZwGENF+B1YCaaIAHQV2 3slCVhVKLP6tlXqdfBMZZeonXSvvqiri5ebYLP82oj2F2t+FAlzGT/p3sy0GmedfRy AYv8RfsIK769LON5MYvVbjsw8NH+eHE/pZrvaWkQ= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 13FE344C38 for ; Fri, 8 Nov 2024 09:00:39 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=gTXDkaXh; dkim-atps=neutral Received: from s.wfbtzhsv.outbound-mail.sendgrid.net (s.wfbtzhsv.outbound-mail.sendgrid.net [159.183.224.104]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 1085F44AFF for ; Fri, 8 Nov 2024 09:00:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=4ROPxuMfpjxjVnh3u0yGqvdyT7i7crYCHFnXXbDoEaA=; b=gTXDkaXhauNyiIx6Q63sd4/A004yJGl8TS0TUlStgwBJhJrKOJkFbOygjYNhskm0ByOr kbYbsmQSQBrbffYuNiSJiVPgJg4T0cnHZHLL/yhv74nmddrBWpZFIlgkxPgyBMFzf99Y5J fH0RHYZRz0Bwlx8xmOR9c+5VqiU27fo4M7FzegHhXH6MNBTug1WTjCxoGCKy1UAJOQku54 BUZ2+T+H5UX4VGpRtQrxD+IQEY/H1zok91JP+RK7oR5hzB1Fp0Uq3rkbr3gVd9umSq8WE5 gChH0hZzSTmeRc8Uj90psnkDGJLX9a5wk2y1WsVJ/d/R3YSl0g2/561a8rdBrFNg== Received: by recvd-94b86bfcc-vz7br with SMTP id recvd-94b86bfcc-vz7br-1-672DD32B-1B 2024-11-08 09:00:27.202176077 +0000 UTC m=+4892658.232661101 Received: from herokuapp.com (unknown) by geopod-ismtpd-22 (SG) with ESMTP id KLEZddSfQq-LE6PO6OkJwg for ; Fri, 08 Nov 2024 09:00:27.085 +0000 (UTC) Date: Fri, 08 Nov 2024 09:00:27 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 20864 X-Redmine-Issue-Author: ioquatix X-Redmine-Issue-Priority: Normal X-Redmine-Sender: shyouhei X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-Redmine-MailingListIntegration-Message-Ids: 96504 X-SG-EID: =?us-ascii?Q?u001=2EYb+gxajettXtIRRbovldwe1q9pj4BbUVLgkglfGACSriEdKOm=2FiYoqOLj?= =?us-ascii?Q?03lPXujlro4oiTXwkRMLtmbf5mY+2Uv33JJiwU+?= =?us-ascii?Q?ZJeKxsg2=2FpahNNr7V1Y3AcXLXvFGmkynkEGFmyF?= =?us-ascii?Q?17dn0VJi7rhi3S2d=2FFvgmZnnGdh8WKrrG6P3tln?= =?us-ascii?Q?B6pHNuqc+JzkEx9kXf7HBig9AwrC0ZiIs5gI3Y4?= =?us-ascii?Q?e7sbbg1TtU2n+254siOEZS9ipZFEC7dKTEaIz6E?= =?us-ascii?Q?9KoR8RZ8vnHHixZHfsI2Z9uvuQ=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: GTCK7DBMHGTSOIDEZAUGZATCOTE5MZIW X-Message-ID-Hash: GTCK7DBMHGTSOIDEZAUGZATCOTE5MZIW X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:119837] [Ruby master Feature#20864] Allow `Kernel#warn` to accept `**options` and pass these to `Warning.warn`. List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "shyouhei (Shyouhei Urabe) via ruby-core" Cc: "shyouhei (Shyouhei Urabe)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20864 has been updated by shyouhei (Shyouhei Urabe). I also want something like this. In order to move things forward we have to clear some points: - There could be programs that redefine `Kernel#warn` on the fly in the wild. They might suffer from the API change. About the only thing we can do here is let them die miserably. Is it an acceptable choice? (I guess so though) - The other issue is `Warning.warn` side. We already have it, which also doesn't expect unknown arguments for now. We acknowledge that Warning.warn could take exactly one argument (per https://bugs.ruby-lang.org/issues/17122#note-15). We are checking if it takes `category:` every time now. If we were to pass arbitrary keyword arguments to Warning.warn is the check... kind of possible in practice? These two might be related, but are not the same thing. ---------------------------------------- Feature #20864: Allow `Kernel#warn` to accept `**options` and pass these to `Warning.warn`. https://bugs.ruby-lang.org/issues/20864#change-110525 * Author: ioquatix (Samuel Williams) * Status: Open ---------------------------------------- ## Background Structured logging is a practice that organizes log data in a consistent, easily parseable format. Unlike traditional unstructured logs, which often consist of plain text entries, structured logs format information in key-value pairs or structured data formats such as JSON. This allows for better automation, searchability, and analysis of log data. In Ruby, `Kernel#warn` is extremely useful, especially because there is a mechanism for loggers to redirect warnings using the `Warning` module. However, it is difficult to generate structured logs with `Kernel#warn` as all the positional arguments are converted to a single string, and arbitrary keyword options are rejected. As a consequence, code like this is not possible: ```ruby begin ... rescue => error warn "Something went wrong!", exception: error end ``` It is very desirable to have a standard interface in Ruby for emitting structured warnings. ## Proposal I'd like to extend the current implementation to allow all options to be forwarded to `Warning.warn`. This would allow us to add more details to warnings and emit structured logs using `Warning.warn`. A simple example of the proposed interface: ```ruby module Kernel def warn(*arguments, uplevel: ..., **options) # Existing processing of arguments -> message ::Warning.warn(message, **options) end end ``` Current behaviour rejects any unknown options: ``` warn("Oops", exception: error) # => :50:in `warn': unknown keyword: :exception (ArgumentError) ``` I don't have an opinion about the implementation, but I wanted to get feedback on the interface. Regarding the default behaviour, I propose no changes. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/