From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package. Date: Wed, 21 Dec 2022 00:01:58 -0500 Message-ID: References: <167139941586.12438.1105626110857907494@vcs2.savannah.gnu.org> <20221218213656.56E0AC0061B@vcs2.savannah.gnu.org> <875ye51wc3.fsf@melete.silentflame.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4124"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Sean Whitton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 21 06:03:08 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p7rFz-0000u4-SW for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Dec 2022 06:03:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p7rFA-0001ey-8M; Wed, 21 Dec 2022 00:02:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p7rF6-0001ed-S2 for emacs-devel@gnu.org; Wed, 21 Dec 2022 00:02:12 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p7rEy-0003Eg-T0 for emacs-devel@gnu.org; Wed, 21 Dec 2022 00:02:11 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0D03C8056A; Wed, 21 Dec 2022 00:02:02 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E448280258; Wed, 21 Dec 2022 00:01:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1671598919; bh=bvJKdWCDtrzAEIqaO2Sz4RKA8jfL9bVFPKZCaih3V4k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DIm8q6lCXyn4pKLvGcU6s5LZI1n6qFNna1S8Sn5dQqd+anin0DawwkhfqoA+WUQ0i BFt8MoERLmMh18fv9udhVqVdkMQ5tcC9Fgi9qPpgt88zo1WVNiojAKdDqkA0YfboYI RFORisrtqWiQ38eM/Hvl5AbaRj+ua1SbdOSC6LzEh2RfqyRMRPqPIMExhKSv3tn6yE dmyMQ561rvz1MpaoDlqonfxL5sYGpoyry278wvLOlGIkwrIBa+1GOpu0UxrH7tsRy6 ecs0RQj/BCw7stFpUCsdoP65QjhPjoxv4u2mQA9xMzx/k+/Ai2CoydBEQoZ+jhqnur pgfX1LKUt4wqg== Original-Received: from pastel (unknown [45.72.200.228]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B9F7F120F9F; Wed, 21 Dec 2022 00:01:59 -0500 (EST) In-Reply-To: <875ye51wc3.fsf@melete.silentflame.com> (Sean Whitton's message of "Tue, 20 Dec 2022 16:36:44 -0700") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:301726 Archived-At: >> Reads hellish to me. This is crap *we* have to maintain in response to >> whatever happens upstream. > > I think that maintaining notmuch.el inside the rest of notmuch.git is a > reasonable choice by notmuch upstream; I do the same in two of my > projects where the non-Elisp heavily outweighs the Elisp. I'm not blaming them. I do think nowadays their users would be better served by decoupling the two, tho. And indeed, the Debian package `elpa-notmuch` does not depend on a specific version of the `notmuch` tools, so in practice the two seem to be sufficiently decoupled that they can evolve separately. > Perhaps we could overcome this particular limitation in the scripts. > How about adding :files or :include, or similar, where if that's > present, then only files matching the globs listed are taken up, and > everything else is ignored? The problem is not with the tarball, but with the Git side. (Non)GNU ELPA is not just an archive of tarballs, but it's built around Git repositories hosting the relevant code and its full history. While I hope Git grows support for "partial clones" (or more likely is superseded by something else which does support such things), the current situation is that you just can't do that. Which means `elpa-diffs` will be spammed with irrelevant commit to the non-Emacs part of Notmuch, for example, and `package-vc` will still have to download the 10MB of Notmuch's repository just to get at the relevant 0.5MB. The closest we can get, AFAIK, is to run an interposer repository which fetches from https://git.notmuchmail.org/git/notmuch and filters the `emacs` subtree into a new branch, and then add *that* branch to `elpa-packages`. Of course, that creates a whole parallel history, so it may end up biting us down the line, but I think given the current situation it'd the "least wrong" way to do it (The Right Way being if they do that split upstream and then use the new branch as the official upstream). > (Additionally and less importantly, I would like to add mailscripts.el > to NonGNU ELPA, as you know, and mailscripts.el depends on notmuch.el.) I understand the desire to add Notmuch, yes. I'd be happy to see it in (Non)GNU ELPA as well. >>> + ;; Alternatively, could we have elpa-admin run 'make emacs/notmuch-p= kg.el' >>> + ;; before looking for a version? >>> + :version-map ((nil "0.37" "0.37"))) >> This 3rd element should be a Git revision (IOW a commit id). > 0.37 is a committish,[1] if not a commit; "0.37" of what? Remember we're talking about `nongnu.git` which contains *all* the NonGNU ELPA packages. So, upstream tags don't make much sense there (and for that reason also they're not pulled from upstream). > isn't that okay? [ And hence: no, it's not okay, I'm afraid. ] It would be good to add optional support for using Git tags to label versions (probably via renaming the tags from `` to `upstream//` or something like that), but I'm still waiting for Someone=E2=84=A2 to write that code. Stefan