Oleg Pykhalov <go.wigust@gmail.com> writes:

Heya Oleg, thanks for chiming in.

> Propagated inputs could lead to conflicts in a Guix profile.  The
> simplest example I could remember is - you want upgrade package ‘A’
> which propagates ‘direnv’, but you cannot because package ‘B’ propagates
> it too.  In this case you need to upgrade both ‘A’ and ‘B’ or delete ‘A’
> (or ‘B’).

Would there be a conflict if they both propagated the same input (in
this case the direnv binary)?

> Instead we could make the package functional by substituting in
> /gnu/store/…-emacs-direnv-…-checkout/direnv.el file ‘direnv--detect’
> ("Detect the direnv executable.") procedure which could return a path to
> ‘direnv’ binary as a string directly without calling ‘executable-find’.
> WDYT?

In general, I like to keep packages as close to their source as
possible, but I'm slowly learning that this is not often the case when
packaging things (which is a shame and a risk in my opinion).

But all things considered, I think this is probably the right approach
here given the feedback I'm getting.

Here's a patch which should supersede the previous patch: