Re: Reacting to package load

[Psionic K <psionik@positron.solutions>]

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


-- 

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