[bug#39384] [PATCH] gnu: Add emacs-rg.

[LaFreniere, Joseph]

Efraim Flashner <address@hidden> writes:
> On Thu, Feb 06, 2020 at 06:47:23PM -0600, LaFreniere, Joseph 
> wrote:
> > Marius Bakke <address@hidden> writes:
> > > "LaFreniere\, Joseph" <address@hidden> writes:
> > > > Ah, I see what you mean now.  But wouldn't hard-coding the 
> > > > path to
> > > > ripgrep in that way prevent the package from being able to 
> > > > use
> > > > remote systems' ripgrep binaries when running over TRAMP?
> > >
> > > Perhaps we could patch [emacs-rg] to do both?  Use the store 
> > > prefix if
> > > it
> > > exists, and fall back to searching in PATH?
> >
> > What would be the advantage of that over just searching PATH to 
> > start with?
>
> It will still work even if you don't have ripgrep specifically
> installed.

Can you point me to the Guix documentation where the functionality 
you're describing is explained?  I have read through the 
description of package inputs in section 6.2.1 of Guix's manual, 
but I still do not explain what advantage patching the search path 
offers.

My understanding is that if we want to preserve both local and 
remote-via-TRAMP functionality, we can either
- just include ripgrep as a propagated input, or
- include ripgrep as a propagated input _and_ patch the package to 
 look for ripgrep in a hardcoded location (for local) as well as 
 PATH (for TRAMP).

Both options would have ripgrep included as propagated input.  As 
soon as ripgrep is installed in a user's profile, its binary will 
be available on PATH.  If that is correct, then I don't see any 
advantage to patching in a hardcoded path to ripgrep.

--
Joseph LaFreniere