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: Sun, 08 Aug 2021 16:03:40 -0400 Message-ID: References: <87y29cj65y.fsf@posteo.net> <87tujzkbu0.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="35229"; 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 Sun Aug 08 22:04:44 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 1mCp2J-0008w2-QC for ged-emacs-devel@m.gmane-mx.org; Sun, 08 Aug 2021 22:04:43 +0200 Original-Received: from localhost ([::1]:55080 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mCp2I-0001uf-KM for ged-emacs-devel@m.gmane-mx.org; Sun, 08 Aug 2021 16:04:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36980) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mCp1R-0001Du-3j for emacs-devel@gnu.org; Sun, 08 Aug 2021 16:03:49 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46960) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mCp1M-0000n1-JG for emacs-devel@gnu.org; Sun, 08 Aug 2021 16:03:47 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7CFEF1000F8; Sun, 8 Aug 2021 16:03:42 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3452010019F; Sun, 8 Aug 2021 16:03:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1628453021; bh=IoHqsZYLRh4TsRY0xR6OBjSargl4wLF2XbBOvra6RBk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=gsV+OV0wMF5Q690tZaLxwaRcNQmJxXsgMtwnuDuiVz/rZ7zLCtL8DLBeN9jO/Kj8J xAN7AvO0JFySVFs4xrAwaKtOXUaqs86MIWe4T0u3QwkTy8OZyAgNBNsLexrw91T89d BXsjrJ9XBjd7CG7Kb94aSRxkqZqPH2FQuMmJOo6S8r/kr4p3U2lXMgjrAzzbAkEjv0 Fdj7xyTpeN7WAkjchltSg7Ab38KzXW5kNcn0rzsxU9aHcwQwMk5vptt7emffnpzZZc xVRyIEq1e/7D78EFN2bVf32CO/wFV6oh0JFsV/6q6l5rx9O2/XYkNtZ88N98BA6DAJ Midr1XDxM1GoA== Original-Received: from alfajor (unknown [216.154.29.138]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 07A6A1202DB; Sun, 8 Aug 2021 16:03:40 -0400 (EDT) In-Reply-To: <87tujzkbu0.fsf@posteo.net> (Philip Kaludercic's message of "Sun, 08 Aug 2021 18:53:11 +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:272210 Archived-At: >> FWIW, I use `elpa-admin.el` for that. >> The advantage being that the package.el is made aware of them. > What is the advantage in making package.el aware? It lets you install `dash` via Git and then install packages that depend on `dash` via `M-x package-install`. >> Admittedly, `elpa-admin.el` doesn't provide that "out of the box", but >> I'd welcome changes to improve this use case. It go become an >> alternative to `straight.el`. > On the topic of package.el, a more general idea I had was to make > package.el more generic, with different backends. I think most of it is there already: package.el is divided between a part that activates packages that are installed and a part which installs packages from ELPA archives. The part that activate the locally installed packages is quite independent and doesn't care about the format of ELPA archives. All it cares about is the contents of -pkg.el and -autoloads.el, both of which are created by the installer. Stefan