Reacting to package load

Reacting to package load

[Psionic K]

I need a strategy to detect when a package is loaded so I can look for a
header (or predetermined override) to install non-elisp dependencies for
that package.

If there's a hook or functions variable, I can't guess the name.  Not sure
where I might add advice if that's the best available approach.

I need an approach that is agnostic to package managers.

-- 

남백호
대표 겸 공동 창업자
포지트론

Re: Reacting to package load

[Eli Zaretskii]

> From: Psionic K <psionik@positron.solutions>
> Date: Sat, 25 Nov 2023 21:54:47 +0900
> 
> I need a strategy to detect when a package is loaded so I can look for a
> header (or predetermined override) to install non-elisp dependencies for
> that package.
> 
> If there's a hook or functions variable, I can't guess the name.  Not sure
> where I might add advice if that's the best available approach.

Is eval-after-load what you had in mind?

Re: Reacting to package load

[Björn Bidar]

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.

Re: Reacting to package load

[Psionic K]

> 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.
>


-- 

남백호
대표 겸 공동 창업자
포지트론

Re: Reacting to package load

[Psionic K]

After sending that I started thinking about blocking and user experience.
In the case of checking for an existing dependency, it's fast and can
happen synchronously.  In the case that we would need to obtain the
dependency, it's usually slow.  In order to complete the load
asynchronously, more cooperation would be needed.

This is all quite edge case since most well-done packages can dynamically
resolve their dependencies and user actions to install from ad-hoc
dependency sources is usually not automatic and certainly not at load time.

`executable-find` might be something I look at since it can co-opt a badly
behaving package, but this also runs into the lack of asynchronous
capability to defer the rest of execution after the co-opting is completed.

On Tue, Nov 28, 2023 at 11:12 AM Psionic K <psionik@positron.solutions>
wrote:

> > 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.
>>
>
>
> --
>
> 남백호
> 대표 겸 공동 창업자
> 포지트론
>


-- 

남백호
대표 겸 공동 창업자
포지트론