From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0EoFMU3Dh2AWfAAAWB0awg (envelope-from ) for ; Tue, 27 Apr 2021 03:54:53 -0400 Received: by simark.ca (Postfix, from userid 112) id BADDF1F11C; Tue, 27 Apr 2021 03:54:53 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 58C571E01F for ; Tue, 27 Apr 2021 03:54:52 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 50E173846035; Tue, 27 Apr 2021 07:54:51 +0000 (GMT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id A1F1B385801A for ; Tue, 27 Apr 2021 07:54:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A1F1B385801A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wm1-x333.google.com with SMTP id g65so2074933wmg.2 for ; Tue, 27 Apr 2021 00:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=oeiydFPeuxargmo94Klwj9bNzbQDHiNWvuU6xbI1KFs=; b=SImLGuJUFMc7K1iKUTmwTpwu9iBPOPEn5eISVYvUfXMGCVQ+ChpTI4Ae4ejBCsmwnV i4fHW2ShRGJaZ2589YuNR3D6iJydcxYbg1AziJ/fAznKOh+eaF9D41RBf+7biuXznyU2 ydukccMa96Nn/ncCoZC9Rz76P1B693E2E4N+MNOGGwcTogPnvWjlZj4D7MG8roVBaWAy UQ1P+FW7i6OaIYtdWC6Rk2oU8upa2rvb8eOe/ptEvR4Oxat5Iyn8w5DIv0N3hyV8Y/3R /oz87mozokpS8IlDb3ZdVvNirHBhBx6kzy11cBqHBhSUT01eGXWhJNYgZ6sEtViCvjTt M/vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=oeiydFPeuxargmo94Klwj9bNzbQDHiNWvuU6xbI1KFs=; b=D2G3xaR7rsArD2UhyteqzPvnwbzdcZ4dUjy3bG7NmMWz813EhOEKFTWEJ63eEZDMKI hfqgrAk5Ie7tM/w4mkGGOaYb3ogxZKV7LiyJYJ7PDt1TcsQOqrfm+fcuHBHMVpZLnlAY qhUHBDOXxy+yBRQI0I0RKDrjXsQDxHPJTE703QhP+ZmEoYbQDL+m48LI2TIsST86x1dt wry0kX9RS/a/AjospNja3+vFhcshj+wXur6FBWEKbHZjbOC73Qz+eVxTO3jJefuZfgzU tfohz+w99VpeiZkcy6ZGdNB3281UC3AU8//fzjZv+t3yLTnYdy6QEXaE/T691B0lm+I9 dIIg== X-Gm-Message-State: AOAM53179IN2cmbqCRdyGOhEfd3kaRAIhWof7ShZcd/NvgqWjORc2rts tSCyp/WPff5G5dp8PpWVXn4rHtdbCcZP6Q== X-Google-Smtp-Source: ABdhPJyo/wvZ2+b64AHETSTx90xQs6w3oEoMMlA0/Gf5RXIA1cXul5+dQbSV8ko0tX9CRvnIBexjUg== X-Received: by 2002:a1c:4954:: with SMTP id w81mr2956704wma.49.1619510086581; Tue, 27 Apr 2021 00:54:46 -0700 (PDT) Received: from localhost (host109-151-46-70.range109-151.btcentralplus.com. [109.151.46.70]) by smtp.gmail.com with ESMTPSA id b1sm3433123wru.90.2021.04.27.00.54.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Apr 2021 00:54:45 -0700 (PDT) Date: Tue, 27 Apr 2021 08:54:44 +0100 From: Andrew Burgess To: Simon Marchi Subject: Re: Proposal: format GDB Python files with black Message-ID: <20210427075444.GW2610@embecosm.com> References: <20210426162149.GU2610@embecosm.com> <20210426175022.GV2610@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 08:49:43 up 16 days, 18:36, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" * Simon Marchi [2021-04-26 14:08:24 -0400]: > On 2021-04-26 1:50 p.m., Andrew Burgess wrote: > > So without going more sophisticated as you describe below we'd still > > be relying on reviewers to either (with enough experience) "just know" > > that the code is black formatted, or apply the patch, run black, and > > see if the formatting changes. > > The use of black would be documented somewhere (in the repo, in the > wiki, or both). Nevertheless, I don't expect all contributors to know > about it and do it. > > I also don't expect reviewers to be able to spot code that isn't > black-compliant. If you think of checking it or asking about it in a > review, great. Otherwise, I don't think we should be too afraid of > errors slipping in, since they're trivial to fix. > > But to be frank, as a reviewer today, I don't really know what to check > in the Python code formatting. Our wiki: > > https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards > > says that we follow PEP8. I have no idea how to format PEP8 code, so > as a result I'm not really checking the formatting of Python code today. > > > Then of course, there's the questions about what happens when > > different users are running different versions of black - assuming > > different versions might format things slightly differently. > > Indeed, I should have mentioned this: we would define a version to use, > just like we do for autoconf/automake. > > The goal of black is that the output won't change just for fun, but it > could change due to fixed bugs. > > > Another concern I'd have is that unrelated "formatting" changes might > > creep in. > > > > So, I edit a .py file and either don't run black (naughty), or use > > version X of black. > > > > Much later, I edit a different part of the same file, now either I run > > black, or run version Y of black. My original edit is reformatted > > slightly differently. > > > > My assumption is that this change (the second patch) should be > > rejected at review, as the reformatting change (of the earlier code) > > is unrelated to the work of the second patch. But I suspect some folk > > might find it frustrating, if on one had we say run black, but on the > > other hand we say you need to exclude unrelated chunks. > > This is why I think it's easier to start from a clean state, by > formatting everything in one shot in the beginning. > > If the issue you describe happens while I am writing a patch, I would > notice the spurious diff and push an obvious "Format foo.py with > black" commit and rebase my WIP patch on top. > > If the issue you describe happens while I am revieweing a patch, I would > probably also push an obvious re-formatting commit (or ask the person to > do so, if they have push access). The offending hunk will go away when > they rebase, which is necessary prior to pushing. > > > I think, in the heterogeneous environments we all develop in, > > situations like the above will crop up, so it would be important to > > know what the expectations would be in such a case. > > Indeed. I hope I was able to show that these situations can be handled > easily and are not a showstopper. Thanks for taking the time to reply. I have no objections to adopting the use of black, my only request would be that we formally make it a policy that "rogue" re-formatting hunks, as we discussed above, should be fixed in a separate commit, and not included in random patches. For me, one of the great things about working on GDB is the generally good quality of the commits, and I feel that if commits start including extra reformatting this would be a step backwards. > > >> > >> If we want to be a bit more sophisticated, we could check-in a git > >> commit hook that runs black (if available) to check your formatting as > >> you are committing, if your commit includes changes to Python files. > >> That doesn't prevents formatting errors from slipping in the repo, but > >> it's already a good start (and formatting errors slipping in the repo > >> are not the end of the world). > > > > Again, this sort of thing works great in a corporate environment where > > you can guarantee that everyone is (or has no excuse not to be) > > running the exact same version of every tool. > > Even in corporate environment, you can't assume that! I disagree, but I suspect the problem is I didn't explain myself well enough. Never mind, given the above I think you've answered my questions. Thanks for your time, Andrew > > > My concern would be that such a strategy would invite unintended > > changes to creep in. > > > >> > >> We don't really have CI right now (especially pre-merge testing), but if > >> we had, checking the formatting of Python files could be a validation > >> step. > > > > Agreed. > > > >> We do however, have scripts that run server side on push, so it would be > >> possible to run black server-side to reject commits that would introduce > >> formatting errors. > > > > I guess this would solve a lot of the problems I'm concerned about. > > Once we've "corrected" the formatting of all .py code then nobody > > could merge bad code. > > Thanks, > > Simon