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: Easy configuration of a site-lisp directory Date: Wed, 25 Aug 2021 13:27:04 -0400 Message-ID: References: <87y29cj65y.fsf@posteo.net> <87tujgv7y1.fsf@gmail.com> <87h7fd93pu.fsf@posteo.net> <87a6l57ew7.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32393"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 25 19:28:54 2021 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 1mIwhp-00089S-W6 for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Aug 2021 19:28:54 +0200 Original-Received: from localhost ([::1]:39898 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIwho-0003tR-CA for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Aug 2021 13:28:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mIwgD-0001c1-Eh for emacs-devel@gnu.org; Wed, 25 Aug 2021 13:27:13 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:37504) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mIwg9-0001ad-P6 for emacs-devel@gnu.org; Wed, 25 Aug 2021 13:27:12 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 55FC3440A5D; Wed, 25 Aug 2021 13:27:07 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id AD031440A53; Wed, 25 Aug 2021 13:27:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1629912425; bh=1HT8DJGzonOcbz5C7w4TBWFGC6p/+FdMr3zZyabSxno=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=YrmAY54lR+D3E0wkkvb2oVeNMjda2U3wYkKdgWy67pUixbG5clQx++MK4cAUOBYnK qtQI9VcKLFBicnZ4pjBuCDwnUynr+uEXHRmoLHTibsASAqFr6jtGzyKpFKCAq/mPEe SZZXv82u+QUJG20NNRzQSCGHV8GIwWdj7b9bayuwo9Tmou+OYEYnBMnu1Pgo1p2PDG KwVhCb/+hZfaOrueCrxp7Jk1EJkB+PEwMVdZFBYBAxrazPW9zB1JMUXnbdp5TkX9BZ hRmkB9c1rEdrXY27NIwQqsezQbTmeqyfsUzwqzbHMM9Fd1i2HnYCIZxci4KjjlkX3Z mfTGTDee03e4Q== Original-Received: from alfajor (unknown [104.247.244.135]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 86787120294; Wed, 25 Aug 2021 13:27:05 -0400 (EDT) In-Reply-To: <87a6l57ew7.fsf@posteo.net> (Philip Kaludercic's message of "Wed, 25 Aug 2021 14:55:20 +0000") 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.23 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" Xref: news.gmane.io gmane.emacs.devel:272984 Archived-At: Philip Kaludercic [2021-08-25 14:55:20] wrote: > Stefan Monnier writes: >> Philip Kaludercic [2021-08-25 11:13:49] wrote: >>> Stefan Monnier writes: >>>> Max Brieiev [2021-08-23 12:14:46] wrote: >>>>> So is there any conclusion in this long thread about preferable setup >>>>> for the case described in the original post? And making local git >>>>> repositeries be package.el aware. >>>> >>>> From my point of view, the "preferable setup" is for someone to spice up >>>> `elpa-admin.el` to make it more user-friendly for that use-case. >>> >>> I could look into this, because I was intending to work on elpa-admin.el >>> a bit anyway. But this would mean that it wouldn't work OOTB, right? >> >> Not sure what you mean by that, but I'm pretty sure the answer is no. > > My suggestion to add something like site-lisp.el to Emacs itself was to > allow anyone to use unpackaged elisp code on their local system, without > having to manually bother with updating load-path and autoloading. Right, and the approach I use in elpa-admin.el indeed allows that. To recap, here's what it does: - Git clone from upstream into .../somewhere/. - In that directory, create a -pkg.el and a -autoloads.el. - Byte-compile the .el files. - Add `.../somewhere` to `package-directory-list`. The last step is only done once and forall rather than once per package. IOW it acts as an alternative package installer: package.el could/should be split into a part that deals with using (activating) the packages currently installed (i.e. basically `package-activate-all` and the code it uses) and a part that deals with ELPA repositories and installs packages into (and remove froms) `package-user-dir`. [ Side note: the byte-compilation should be moved out of the installation step, not only so it can be shared between different UIs and installers, but also so we can re-compile upon request. ] Then of course you'll want to add further features: - commands to update packages, i.e. do a `git pull` and recreate/refresh the two files. - support for creating Info docs out of Texinfo. - support for packages where the Elisp code is not at the root of the clone but in some subdirectory. - allow the user to choose to select an actual *release* rather than the bleeding edge. The above listed features are those that `elpa-admin.el` currently supports (to some extent, in one form or another), but of course, there could be more. Currently, for many packages all you need is the URL of the upstream repository, but for others we need extra information in the "package spec", such as where to find the Texinfo source. In the context of `elpa-admin.el` the extra info for this "package spec" are provided in the `elpa-packages` file but I think it would make sense to make it possible for the package to provide this info directly (e.g. via additional pseudo-headers in the .el file). Stefan PS: Note also that `elpa-admin.el` includes a fair bit of code that does other things, not relevant to this discussion, such as creating tarballs for ELPA repositories, creating HTML pages, etc...