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: Request to add Package to GNU ELPA Date: Thu, 30 Mar 2023 15:42:49 +0200 Message-ID: <87tty24ap2.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="20691"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 30 16:23:52 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 1phtBs-00050z-Jr for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Mar 2023 16:23:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phtBE-0000xf-RA; Thu, 30 Mar 2023 10:23:09 -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 1phsYK-000109-KL for emacs-devel@gnu.org; Thu, 30 Mar 2023 09:42:56 -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 1phsYH-0005UN-VD for emacs-devel@gnu.org; Thu, 30 Mar 2023 09:42:56 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 3AAA316531 for ; Thu, 30 Mar 2023 15:42:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :subject:subject:from:from:received:received; s=sel2011a; t= 1680183770; bh=vHH9xowKhPfCqo01hXmjlDFssXssJg9I2mipISpRzQc=; b=2 yV1srhWH0u2KQLutleQp9bsHkKG9Uli1M2OzriSODw8nc5bw1rPyMWOkFGtHnUUf FDrJwsVuxj8gBsc2cMZn6jb27H6immgrfSR3D5phgTqidh+e5UAYyjeyOeO/IRqI YmFOaZNjmi/fRyxDoDZ8JibFibZ0gcHSQWlnDkG0pc= 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 BFdRyYxXKVqE for ; Thu, 30 Mar 2023 15:42:50 +0200 (CEST) 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 ED681164F8 for ; Thu, 30 Mar 2023 15:42:49 +0200 (CEST) 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: Thu, 30 Mar 2023 10:23:07 -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:304867 Archived-At: Hello, I would like to request that "package.el" be added to GNU Elpa as a "core" package. This would make new features available to users who are stuck on older Emacs releases and it would even bring us one step closer to being able to make backward incompatible changes in the future. Some examples for why that would be desirable: - A recent addition that could be useful is the new "package-vc.el" (which I think should be distributed as part of the `package' package, but it could also be distributed as a separate core package). That isn't just useful for users who like to live on the edge. For example, if a package drops support for an old Emacs release, then a user who is stuck on that release, may wish to keep using the last release of the package that still supports that Emacs release, and package-vc would allow them to do just that. - I don't use Package myself, so I am not fully aware of all the quality of live enhancements that surely have accumulated over the years. But I am aware of some small missing features, that would be beneficial to users of older Emacs releases. - For example, I think it would be nice if the columns displayed by `list-packages' were customizable. A user might want to increase the width of the "Version" column, so that not every GNU-devel ELPA version is truncated, or they might want to add an "Author" column. We could even allow third-party packages to add columns such as "Downloads" or "Stars". - I should also mention that my main motivation for pushing for this now, is that I would like to improve version handling. That is a whole other can of worms, so I do not wish to discuss it just yet, to avoid distracting from the topic at hand, but I thought I should at least mention it. You might very well end up being against my suggestions regarding versions strings, once I present them, but that should not be cause to oppose the change requested here as well. Even if my suggestions regarding version strings are ultimately rejected, I still think it would be a good idea to add `package' to GNU ELPA, for the other reasons presented here. - I should also make an example for a backward incompatible change. Yesterday, in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62524 I suggested a backward *compatible* change, but doing it in a backward compatible fashion is a bit ugly, and I would like to *eventually* replace it with a backward *incompatible* change. In short, some packages have multiple maintainers and `describe-package' should list them all. Unfortunately `:maintainer' (unlike `:authors') in "archive-contents" can only be a single maintainer. If we listed multiple maintainers, then current versions of Package would signal an error. To address that I proposed that we *add* a `:maintainers' property. Older Package don't know about that property and would simply ignore it, and newer Package versions could start doing all the maintainers justice. It isn't exactly horrible to have both `:maintainer' and `:maintainers' for a while, but it is a wart that should be remove eventually. We should avoid accumulating more and more such warts over time. One way of doing that is to simply avoid adding features that have to be implemented in an ugly fashion to avoid breaking backward compatibility. I feel that approach has been taken too many times in the past. I myself have certainly done it on several occasions. I mentioned that distributing Package on GNU ELPA would bring us one step closer to being able to make backward incompatible changes, but unfortunately it is not enough. Just because `package' is available on GNU ELPA, that doesn't mean that it gets installed automatically. There are two additional steps required. (1) We have to somehow get users to install `package' from GNU ELPA a first time, and (2) once users have done that and a new `package' version becomes available, they have to be informed about the update and be prompted to install it. To address (2), `package-refresh-contents' could be taught to check if a new `package' version is available, and if that is the case, then it should prompt the user to update that immediately, before any other packages. Addressing (1) is harder, and I don't think it possible to do so in a way that guarantees that not a single user would end up seeing an error due to an incompatible change. On the other hand "archive-contents" comes with a version field, and if we bump that, we at least get a meaningful warning: "Package archive version 2 is higher than 1". This doesn't say that the solution is to install `package' from GNU ELPA, but it should be enough to feed into a search engine to get to that answer. Additionally, we could get many users to install `package' from GNU ELPA, by making a few popular packages explicitly depend on a `package' version that is available from GNU ELPA for a few months. Thanks for considering this proposal, Jonas