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

["LaFreniere\, Joseph" <joseph@lafreniere.xyz>]

Efraim Flashner <efraim@flashner.co.il> writes:
> On Thu, Feb 06, 2020 at 06:47:23PM -0600, LaFreniere, Joseph 
> wrote:
>>
>> Marius Bakke <mbakke@fastmail.com> writes:
>> > "LaFreniere\, Joseph" <joseph@lafreniere.xyz> 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