[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reacting to package load
From: |
Psionic K |
Subject: |
Re: Reacting to package load |
Date: |
Tue, 28 Nov 2023 11:12:53 +0900 |
> Not in all cases it's good to check for dependencies only after the
depending package was loaded.
Yes, and this will continue to be true for packages that resolve and
configure external dependencies at load time rather than dynamically after
giving us a chance to react. I'm going with after-load-functions for now.
In the future, packages will cooperate with dependency management through a
new package header to communicate which non-elisp packages are required.
Long term, Emacs needs to mediate the implementation of providing external
deps in reaction to loaded Elisp deps. A non-standard hook such as
before-load-functions will enable external dependency managers to pre-empt
missing software before any chance for problems downstream.
To be clear, these dependency managers will be agnostic to Elpaca,
Straight, package.el etc. They don't care what they are doing, just which
package got loaded so they can see if the dependency is already available.
If there's a more obvious extra header name than X-Package-External to
describe a non-elisp dependency, please say so. I am using an X prefix
because I have seen this used for other additional headers that don't have
a standard meaning yet.
The contents of the header needs to accommodate both generic and specific
styles so that more specific declarations can override generic ones
For an example:
X-Package-External: (((nix . "cowsay") (guix . "cowsay") "cowsay"))
Each entry is a list for one dependency. The dependency is specified via
generic paths in a string and then in specific paths with a cons if
necessary.
I'll take a closer look at Guix. I didn't identify anything concerning,
but I've lost familiarity. IIRC both Nix and Guix support more explicit
string paths where necessary.
The external dependency managers and use-package will of course override
packages to alleviate pressure on upstreams, via new keywords and supplying
values for missing headers. In the beginning, this will be the only
available mechanism.
On Mon, Nov 27, 2023 at 6:38 PM Björn Bidar <bjorn.bidar@thaodan.de> wrote:
>
> As Eli already said there's eval after load but there's also
> featurep to check if a feature is present.
> Not in all cases it's good to check for dependencies only after the
> depending package was loaded.
>
--
남백호
대표 겸 공동 창업자
포지트론