From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: GNU ELPA and package.el (was: Tramp as ELPA package) Date: Sat, 06 Apr 2019 18:25:40 -0400 Message-ID: References: <20180819204918.GA3934@ACM> <20180821162043.GA3946@ACM> <20180823213418.GA32596@ACM> <83lg8w9mt2.fsf@gnu.org> <871saoc70o.fsf@gmx.de> <87wosebzur.fsf_-_@gmx.de> <87tvnh9yg6.fsf@gmx.de> <8736myq6wo.fsf@gmx.de> <87y34o704v.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="193335"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 07 00:26:28 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hCtla-000o9o-SW for ged-emacs-devel@m.gmane.org; Sun, 07 Apr 2019 00:26:26 +0200 Original-Received: from localhost ([127.0.0.1]:59677 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hCtlZ-0000q6-TM for ged-emacs-devel@m.gmane.org; Sat, 06 Apr 2019 18:26:25 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hCtl0-0000nf-13 for emacs-devel@gnu.org; Sat, 06 Apr 2019 18:25:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hCtky-00069P-Kj for emacs-devel@gnu.org; Sat, 06 Apr 2019 18:25:49 -0400 Original-Received: from [195.159.176.226] (port=35352 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hCtky-00069J-Ba for emacs-devel@gnu.org; Sat, 06 Apr 2019 18:25:48 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hCtkw-000nSP-OS for emacs-devel@gnu.org; Sun, 07 Apr 2019 00:25:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:ij4z+hgiwl4inHGHPISktZdPsEs= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235043 Archived-At: [ Changing title since it's not specific to Tramp. ] >>> Would it be possible to go the same line as org-mode has done? >> I want to get rid of this Org hack, so I'm really not looking forward to >> adding more such exceptions. > As discussed before: The package requirements are too limiting to allow > larger packages that need to have something built or generated (or even > multiple autoload files) and it's not just Org that falls into this > category. I'm fully aware of that. But you can push the prebuilt packages to elpa.it rather than pushing them to some third-party distribution site, and let elpa.gnu.org build the corresponding tarball. This is the only thing needed to eliminate the "Org hack". This said, I'd love to get some help improving the elpa.gnu.org build scripts so we can lift those restrictions altogether. [ Basically, I'd like to be able to run those package-provided extra build rules in some kind of sandbox, e.g. an LXC container; but given the limited resources of elpa.gnu.org and its maintenance, it should ideally re-use the Debian install already provided by elpa.gnu.org. ] > The other unsolved problem is that anything that gets built in to Emacs > releases still can't be later cleanly updated as a package because none > of the "built-in packages" are actually packages in the ELPA sense. I don't know what problem you're thinking of. You can definitely upgrade Org, python.el, and several others. I can imagine scenarios where it can partly break, but most of them seem contrived to me, so if you know of practical problems, please let me know. > Last but not least I'll mention again that even if the two points above > were solved, there still is not mechanism to cleanly separate packages > installed at the system level (either with the Emacs release or > separately by the admin) and user-level packages. Specifically, if > packages are installed at the system level, the user can either use them > all or none of them, but can't really chose on a per-package basis > (without jumping through a number of burning hoops, that is). Currently, this choice is made via package-load-list. That was the initial way to do that, and there hasn't been much noise about it since, so it hasn't seen much activity, but we could make it more flexible if needed. How do you imagine the user making this choice? You mean you'd like to have a "clickable UI" or something else? >> What you can do is create a Tramp package on elpa.git and push releases >> there (complete with the pre-built auxiliary files). > Well, that'd be more or less the same hack as you use for Org, except > you use Git instead of an archive file. That's a big difference for the build scripts. >> This is what AUCTeX does, basically (where the files that would >> ideally be auto-generated during packaging are instead stored in the >> elpa.git repository after making them manually). > That is a mistake and should not be forced on anyone. I don't consider it a feature, but other than complaints, I haven't gotten much help in trying to improve the situation. Stefan