From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: feature/package-vc has been merged Date: Wed, 09 Nov 2022 20:32:13 +0000 Message-ID: <87pmdv98du.fsf@posteo.net> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <874jvcowzm.fsf@posteo.net> <83y1soypvx.fsf@gnu.org> <87y1song5x.fsf@posteo.net> <83v8nsyof7.fsf@gnu.org> <87leoond7l.fsf@posteo.net> <83r0yfzz01.fsf@gnu.org> <87bkpjyx3p.fsf@posteo.net> <83bkpjynmj.fsf@gnu.org> <87iljqya44.fsf@posteo.net> <8335auzo9s.fsf@gnu.org> <87zgd2ws8z.fsf@posteo.net> <831qqezkxj.fsf@gnu.org> <87y1slgq3m.fsf@posteo.net> <87bkpgfsqv.fsf@posteo.net> <87educ9fei.fsf@posteo.net> <8735as9cfb.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="11455"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , rms@gnu.org, emacs-devel@gnu.org, Lars Ingebrigtsen To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 09 21:33:12 2022 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 1osrl0-0002fs-6l for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Nov 2022 21:33:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1osrkI-0006UC-Qk; Wed, 09 Nov 2022 15:32:26 -0500 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 1osrkH-0006U4-AD for emacs-devel@gnu.org; Wed, 09 Nov 2022 15:32:25 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osrk9-0002br-LS for emacs-devel@gnu.org; Wed, 09 Nov 2022 15:32:24 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D6CDA240027 for ; Wed, 9 Nov 2022 21:32:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1668025933; bh=1qTdA85ewWPyOoZSFZHx+HXwOf8+FgUr1mKqOxnstWA=; h=From:To:Cc:Subject:Date:From; b=oJWn+3I9ReeJjnn0psPVViWN9OMpzk4eTI8G8Roe9IUfDZNKFgBI3Bz0HtwTRjODI NgOkecfiw30iX6kPrjcXtF4fj0973ZXJbXiVjHG1p7nbixIhhpNQQ5R5T2h2h6bvGv L3DzfoKFdi/Qwyi85b0DQYeybbnNBL+XVN6XtTxqt1gCmVF9sSVARKZxt6N9c++ym4 lxybLTbleIIqdUrubCbQ0Esi33eFREaIlP8nBAtOk6P3zNO0ZwyjfdSB+Dcs4m4g1S RSSpnyxMEFJXMJfvgOduOYXyY1aYT2aPksZj8Mt8YFhErKyfnL6EaE5PTGYu3QLAHM tXPaO9IMBDZLA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N6xTm5hNmz6tnx; Wed, 9 Nov 2022 21:32:12 +0100 (CET) In-Reply-To: (Stefan Monnier's message of "Wed, 09 Nov 2022 14:53:00 -0500") Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:299430 Archived-At: Stefan Monnier writes: > Philip Kaludercic [2022-11-09 19:04:56] wrote: >> Stefan Monnier writes: >>>> I have made :lisp-dir a general property of a package description. This >>>> might be set in package-vc when generating the -pkg.el, but in >>>> principle any (non-vc) package could make use of this to indicate a >>>> subdirectory where lisp files are stored. For now this is something >>>> that will probably only interest package-vc. >>> >>> Hmm... but if a package does that in an ELPA archive (i.e. the >>> `:lisp-dir` thingy appears in the `archive-contents`), then this package >>> will not be installed correctly when installed with an older >>> Emacs, right? >>> >>> IOW, it's an extension of the ELPA protocol. >> >> Strictly speaking yes, but without any specification it is hard to say. >> All this is intended as is an extra field that is stored in a package >> description file. >> >> Do you have any other suggestion that could be implemented to solve the >> immediate problem that package-vc has (lisp files are located in some >> sub-directory and we want to avoid loading package-vc during >> initialisation). > > I don't understand the problem you're trying to solve: package-vc > already has access to this `:lisp-dir` info and it can generate the > autoloads file on its own, so I can't see why `package.el` would need to > know about it. You are right, it is not necessary but... >>> I do think it's getting time to update the protocol based on the >>> experience gained over the last 10 years, but I'm really not convinced >>> `:lisp-dir` is a good addition. >>> >>> E.g. a thing I'd find more interesting would be to let the tarball provide >>> its own -autoloads.el (which is in charge of adding whichever >>> lisp-dirs it wants). >> >> That sounds like a better idea. > > But for `package-vc` that's already the case since it has complete control > over how the `-pkg.el` and the `-autoloads.el` are generated. ..., this is handled by `package-vc--unpack-1' which up until now did not depend on a package specification, just a package description. This is so, so that it can be invoked by `package-vc-refresh' or `package-vc-install-from-checkout' which all don't necessarily have specifications. It would be imaginable to store the specification in a file like -spec.eld, but there are too many files already so this is just getting more and more messy. If you believe that this is not worth it or shortsighted on my part, I'll implement the code necessary for what you suggest to work.