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: Unboxed package manager Date: Wed, 22 Mar 2023 12:17:13 +0100 Message-ID: <87lejprq6e.fsf@bernoul.li> References: <57668895-8EEA-44F7-BD46-9CDFAA11FD2C@gmail.com> <87zg87saw8.fsf@posteo.net> <87sfdzqon5.fsf@bernoul.li> 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="29276"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philip Kaludercic , Yuan Fu , emacs-devel To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 22 15:37:48 2023 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 1pezb1-0007QE-SP for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Mar 2023 15:37:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pezaO-00024K-8S; Wed, 22 Mar 2023 10:37:08 -0400 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 1pewT8-00082y-8U for emacs-devel@gnu.org; Wed, 22 Mar 2023 07:17:26 -0400 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 1pewT5-0002I3-SJ for emacs-devel@gnu.org; Wed, 22 Mar 2023 07:17:26 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id CD6F0164A3; Wed, 22 Mar 2023 12:17:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-transfer-encoding:content-type:content-type:mime-version :message-id:date:date:references:in-reply-to:subject:subject :from:from:received:received; s=sel2011a; t=1679483835; bh=GuaKF rSH132AxcjzdeA+5u/KgnkGe4zD2igvCMddf7k=; b=Vz2v3tZUy+K9rZ8N/FIwF 4JQVTTwKU21GPhXmxIHHL1ifVNKm7DTzkL8EdWqTRrWus8wr0RADii0YQOgwzC+m ButqqlBpRXcZshojBg7vAlqiBOWhTsScDj/cAGZD44zhFP51xohQrt1iJYp/oqev 57E17uxljsTdr0tGLqJ0lQ= 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 Zq_BpCcDEgXe; Wed, 22 Mar 2023 12:17:15 +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 783E5164B7; Wed, 22 Mar 2023 12:17:15 +0100 (CET) In-Reply-To: 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 22 Mar 2023 10:36:58 -0400 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:304712 Archived-At: Lynn Winebarger writes: > On Mon, Mar 20, 2023 at 2:11=E2=80=AFPM Jonas Bernoulli wrote: >> >> Lynn Winebarger writes: >> >> > I think I'm going to hack something together starting with advice on t= he >> > existing package management and taking some inspiration from the desig= n of >> > Jonas Bernoulli's epkg and emir packages for tracking installed packag= es >> > and component files in a SQLite database. >> >> If I were to start over now, I wouldn't write Closql. At the time it >> made a lot of sense because I knew nothing about databases and because >> it allowed me to switch out the old data store ("everything is *its own* >> file") without changing internal interfaces much. Moving from files to >> a database did wonders for performance, so at first I didn't mind the >> performance impact of the OO interface on top of the database. >> Meanwhile I have moved away from the OO interface for anything that >> deals with more than one package at a time, turning many rows into >> EIEIO objects is a bit costly. > > Hmm - I had thought it might be an interesting exercise to get > acquainted with Emacs's version of CLOS, but maybe not. That is well worth it. And Closql is at least interesting; it's just that "turn every row into an object" is too slow if you have thousands of rows and all you really want to do is display a table of some of the columns. (If you do use Closql, then use the "next" branch, that would already be merged, if I weren't waiting for two downstreams to act.) > However, just > reviewing the way you've organized the package data is probably going > to be useful. For example, trying to understand the best way to > assess whether a particular version of a package is an upgrade. I > don't know about the behavior of package.el in master, but > historically, if there is a version of a package on MELPA and the same > package is available on GNU or NONGNU ELPA, package.el will treat the > version on GNU/NONGNU as an upgrade even though the one on MELPA is > more recent. I assume it has something to do with the comparison of > commit hashes or dates with more traditional version numbers, but > that's just a guess. I'm afraid I am not doing any of that. I just track the HEAD of the most authoritative repository. > >> >> When I switched to SQLite, Emacs had no built-in support (coming in >> Emacs 29) and there also was no module, so EmacSQL was the natural >> choice. I am the maintainer of that now, so I definitely think it >> serves a purpose, but I do have some reservations. >> >> The next release will feature new backends that use the built-in support >> and a module, but if I were to start now, I probably would go with the >> built-in support directly. >> >> EmacSQL allows writing SQL using vectors instead of concatenating >> strings, which is nice, but for people just getting started with SQL, it >> has the disadvantage that you now have to learn two things, SQL and the >> almost SQL vector syntax, which isn't 100% complete and doesn't map 1:1. >> >> The main limitation of EmacSQL is that it stores everything (except >> NULL) as a string. This is why I would probably avoid it now, because >> it limits interoperability with anything that doesn't use EmacSQL. > > That's only because it was designed to interact with sqlite through a > pipe to the shell program, though, right? No, it was a design decision by the original author, in order to keep things simple. > It seems like a method for > compiling sexpr-type representations of sql queries into statements > usable with the builtin support would still be useful, and not limited > in the same way - since the returned values do not require serializing > as text by the sqlite shell then parsing them in Elisp. Of course "SQL as vectors" and "store everything as a string" are not tied to each other per se, but with EmacSQL you get both. > [ Digression...] > Just looking at the src/sqlite.c in master, as there is no other > documentation of the sqlite support I can see, only a simplified form > of the core API is supported - not unreasonable for an initial > release. The only noticeable absence I see, based on a cursory review > of the sqlite3 API spec, is that a select query cannot be reset. > Maybe because each db connection is associated with at most one > prepared statement at a time by the design of the Lisp_Sqlite > pseudovector? > > Other than that, I note that rows are returned as lists rather than > arrays, which makes the semantics more incompatible with emacsql than > it really has to be. Can that be changed before 29 is released? Why is that a problem? What would we gain if the DSL and the output both used vectors or both lists? > The associated sqlite-mode looks interesting. I only wonder why it > doesn't derive from tabulated-list mode instead of directly from > special. Tabulated list mode would seem to be made for things like > database tables. > > Lynn Jonas