From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jonas Bernoulli Newsgroups: gmane.emacs.devel Subject: Re: [nongnu] main f4166f428a: * elpa-packages (emacsql): New package. Date: Sat, 17 Dec 2022 03:01:49 +0100 Message-ID: <87cz8izt2q.fsf@bernoul.li> References: <167091741978.18640.16217484079810212983@vcs2.savannah.gnu.org> <20221213074340.1C45BC000CE@vcs2.savannah.gnu.org> <87fsdezuh9.fsf@bernoul.li> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16455"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Kangas , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 17 03:03:01 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 1p6MXU-000405-7R for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Dec 2022 03:03:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p6MWW-0000hk-7q; Fri, 16 Dec 2022 21:02:00 -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 1p6MWS-0000hQ-LZ for emacs-devel@gnu.org; Fri, 16 Dec 2022 21:01:57 -0500 Original-Received: from mail.hostpark.net ([212.243.197.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p6MWQ-0004UE-Mg for emacs-devel@gnu.org; Fri, 16 Dec 2022 21:01:56 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 77F9D17628; Sat, 17 Dec 2022 03:01:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from:received :received; s=sel2011a; t=1671242510; bh=yTp7lw5IyK7skneBMv9Cssh+ 5qUZy7wizGeKB6dnP8I=; b=FtyeDMezTaXwaPZ8VC2L+wtwQ7yQ0hZ2+8CpLM0H AJw8t57nG+mkE/e1/PcOtIvd4LGEYkfMDEomuTX2MunQHKloqdvzwDsIQT9Gs7Ua gyaP3qR5SUF0bm4uPpBj5WzHQr9ZDBXXERtE4Erj3KEOQhyJtMsnJbNN5QhZdPwO B8M= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id zrBkhhdU48im; Sat, 17 Dec 2022 03:01:50 +0100 (CET) Original-Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 44C6C16CD0; Sat, 17 Dec 2022 03:01:50 +0100 (CET) In-Reply-To: <87fsdezuh9.fsf@bernoul.li> Received-SPF: none client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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:301536 Archived-At: >> Agreed. Let's see what Jonas thinks about the plan I proposed. > > I am super busy and would like to delay thinking about this and working > on it until next year. > > I might actually come to the conclusion that not splitting up the > package is the right way to go in this case. Or the backends that--to > the best of my knowledge--nobody uses (all the non-sqlite backends), > could be moved to separate repositories. Eventually -sqlite-builtin > will be the default backend, but we still need -sqlite-module, for older > Emacs releases. I intend to deprecate the original -sqlite backend > (which uses a custom executable) in a few months, and I intend to then > remove it from the repository (to get rid of the tracked sqlite.c), but > keep it alive in a separate repository for a while. My current medium term plan is to distribute emacsql.el, emacsql-sqlite-builtin.el and emacsql-sqlite-module.el as a single package and stop maintaining and distributing all the other backends. Packages that use "Emacsql" all want to use sqlite, but it does not matter to them which sqlite backend is used, which very soon will depend on what Emacs version is used. (But unfortunately, dependants need some boilerplate to support the various backends and so that they can leave the choice up to the user. Maybe something can be done about that boilerplate. Distributing these three libraries together would probably help with that.) The reason I don't want to include emacsql-sqlite.el is that I want to move it out of the repository fairly soon (along with all the c code), once the two replacements have proven themselves in production. Since this library is currently being distributed separately, we might just as well keep doing that. If we make it part of emacsql now, then it would only remain there for a while, and then in about a month or two it would be split into a separate package again. The non-sqlite backends are not really used by anyone. I think not distributing them at all, at least for a while, would be a good way to find out if there is anybody who uses them. I don't really want to maintain these backends and would prefer if someone else, who actually uses them, maintained them, in a separate repository. So again, if we include them in emacsql now, that is something that might be reverted fairly soon. But I have to think about all of this some more. The plan was to leave things as is, and deal with it once I actually have the time to do so. The above is just the very rough plan that I mostly formed before you asked me to stop splitting up the package/repository. My suggestion for the immediate future is that you distribute emacsql and emacsql-sqlite as two separate packages and forgo distributing the other backends (neither distribute them individually, nor as part of emacsql).