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: emacs-29 acd462b0306: ; Improve the use-package manual Date: Sat, 10 Dec 2022 17:01:13 -0500 Message-ID: References: <167059642832.4265.15913417645926264658@vcs2.savannah.gnu.org> <20221209143348.961DEC0E4CA@vcs2.savannah.gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39642"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org, Eli Zaretskii , John Wiegley To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 10 23:02: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 1p47vA-000A6E-3P for ged-emacs-devel@m.gmane-mx.org; Sat, 10 Dec 2022 23:02:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p47uW-0002Kr-3n; Sat, 10 Dec 2022 17:01:32 -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 1p47uS-0002HN-76 for emacs-devel@gnu.org; Sat, 10 Dec 2022 17:01:28 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p47uP-0001xt-Le; Sat, 10 Dec 2022 17:01:27 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5A35580499; Sat, 10 Dec 2022 17:01:22 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 713D3805D5; Sat, 10 Dec 2022 17:01:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1670709680; bh=kcdeKy//tb8nS1sZ3HpR3YV7C7+VLnBWgBt/FhbuBAQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lGFqNB7e0A0+l5w3Mtra8XR/egcaCoLqYi33nGBej15dYEqSowHat1RDIAeXuo2Fu WH30jLMXKh49PrMIzHnlq83XvZSqpwuJfme9qCSfPnwRT9eMZ9jLmlufUYgiE1xut/ r1MBl1vuH8Kp2q2mt/6moZgJhav/GIYURG8vIoTI28+CfVEYfjlUEzVIsIqCgBz21G phVBecBvJdJoNViNcTJjnCuycklnmBrjaLC6lwQs6Bhio5YZ84H/kgr6IqYi0acnAL 60jTjLPiW9kjawcJT00Xj6RiBFAlq3Ob5y72O4F9bLpacTKDR6pQGY9VWFQKiQ9gEi WKWG4IdmU2RPw== Original-Received: from pastel (unknown [45.72.193.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3A51E1202DA; Sat, 10 Dec 2022 17:01:20 -0500 (EST) In-Reply-To: (Stefan Kangas's message of "Sat, 10 Dec 2022 12:33:37 -0800") 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.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:301133 Archived-At: >> I think this part of `use-package` is a result of its having been >> designed before things like `package.el` became common practice (the >> main effect of which (in this respect) has been to make `;;;###autoload` >> cookies usable in all packages without any extra work on the package's >> author's side). > > Agreed. Another thing is that `use-package' also tries hard to be > package manager agnostic, and that also shows in places. I wonder if > that's somehow also connected to the above. Im not sufficiently familiar with all the package managers out there, but my impression is that it shouldn't make much difference in this respect. > Is it true that some of the other package managers don't setup > autoloads, or do they all do that? If so, I think it's a problem for them. More specifically, I think setting up autoloads is part of "installing a package" and not part of "customizing a package". This difference is relevant when we need a "clean/vanilla setup" (e.g. for compilation/flymake purposes) in which case we want dependencies to be "fully installed" but not customized. Historically, `use-package` has tended to conflate the two. >> (A similar "old style" thingy is that (use-package foo-mode :mode >> ".bar\\'") will setup an autoload for the `foo-mode` function, whereas >> that autoload should have already been setup by the package's own >> installation). > I agree that it's usually redundant (or should be, at any rate), but it > also doesn't hurt, does it? It hurts in the sense that a subsequent `fboundp` may return non-nil even though the package is actually not installed. > IOW, I'm asking if you think it's necessary to do something about > this, either in our code or documentation, wether in the short-term > or medium? I'm not sure what we should do in the short term, but I think we should keep this in mind when writing the doc to try and encourage writing `use-package` snippets which are "forward compatible" (e.g. don't depend on whether the file gets `require`d, etc...) and to help the users think with a clear distinction between what should be part of installation and what should be part of customization (so they will know when to report a bug for a missing autoload cookie instead of cargo-culting a `use-package` snippet which works around the problem giving the impression that Emacs is more difficult to use/customize than it really is). >> Instead better choices will usually look like `:if (fboundp '...)` >> (which should be a lot faster than `locate-library` and doesn't care >> how the package was installed). > Ah, good point. This is indeed the best solution for packages installed > with package.el, but unfortunately not for manually installed packages. Indeed, `use-package` is great for truly manually installed packages. But these should be a very small minority nowadays, and we should (and do) work towards making it even more rare (e.g. with things like `package-vc`). The doc should focus on the more common case where packages are properly installed with some tool that already sets up the maintainer-provided autoloads. > I am now starting to lean towards setting up a section in the > "Installing packages" chapter for manual package installations, and > just moving all stuff relevant only to that there. Sounds great! > I am also very much starting to lean towards moving the explanations > that should only affect users of third-party package managers to the > info node `(use-package) Other package managers'. I don't know enough about what those differences are to judge, so I'll trust your judgment on that. >>> Alternatively, we could perhaps consider changing the docstring of >>> `package-installed-p' to just let people know of `locate-library' (and >>> maybe even when to use it). >> This doesn't sound right since those two are only distantly related. > Hmm, are they? The latter seems like a more general version of the > former to me, so I'm probably missing something. `locate-library` is normally intended to tell you where a file is along `load-path`. `package-installed-p` tells you whether a package is installed, which could even be true when the package is not activated (i.e. isn't in `load-path`). > People on the use-package issue tracker have asked if > `package-installed-p' will only tell them about packages installed using > package.el. Because they use some other package manager that doesn't > register packages in package.el (I guess), or they have just added some > directories to load-path. Indeed, `package-installed-p` is quite specific to `package.el`. > Perhaps we should just say that those other package managers should be > fixed to better integrate with package.el? (Note that we already > provide `use-package-ensure-function', but that only covers :ensure and > not :if.) To me testing `package-installed-p` is a bit like testing the Emacs version instead of checking the actual thing you need: sometimes it's the better choice, but usually it's not. Stefan