John Darrington <john@darrington.wattle.id.au> writes:

> On Fri, Dec 23, 2016 at 06:11:44PM -0800, Chris Marusich wrote:
>      Leo Famulari <leo@famulari.name> writes:
>      
>      > On Fri, Dec 23, 2016 at 12:16:24AM -0800, Chris Marusich wrote:
>      >> Hi Leo,
>      >> 
>      >> I've responded to the feedback from you, Hartmut, and John.  How does
>      >> the latest patch look?  It's available here:
>      >> 
>      >> https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00707.html
>      >
>      > Thanks for the reminder! I pushed as
>      > 426e6083ae9d4569005dab8edf948485e5979171.
>      >
>      > I think it would be useful to figure out if it's possible to avoid the
>      > wrapper somehow, but I didn't look into this closely.
>      
>      I'm sure we could avoid the wrapper by patching the source, but why
>      would that be better?  The wrapper is a simple and robust solution, and
>      in this case I can't see any drawbacks to using it.
>      
>      For context, Asunder assumes that various tools will be made available
>      via the PATH environment variable.  It refuses to function in certain
>      cases when a tool that it needs can't be found in the PATH.  I'm sure we
>      could patch this mechanism, but it seems simpler to just create a
>      wrapper that puts the directories containing the tools onto the PATH.
>      
>
> FWIW, I think wrappers are  bit of a nasty solution and should be avoided
> if feasible.  Sometimes however there is no reasonable way to avoid them.
> It sounds as if this might be such as case.  J'

Why is the wrapper not good here?  What would be a better solution?

Here's why I think the wrapper produced by 'wrap-program' is a good
solution in this case:

* The wrapper script allows us to package the software without modifying
its source.  As previously explained, Asunder is currently written under
the assumption that the tools it requires will be made available via the
PATH environment variable.

* The wrapper script guarantees "complete deployment" of Asunder (i.e.,
no missing dependencies).  This is because the wrapper script contains
references to the components in the store that provide the command-line
tools that Asunder requires.

* The wrapper script requires less work than patching Asunder.

* The wrapper script is more robust than any patch we might attempt to
  apply to Asunder's source code.

This is a good argument for using a wrapper script in this case.  And I
believe these points apply to any component, like Asunder, which is
written under the assumption that tools will be made available via
PATH.  I also am willing to believe there are cases where the wrapper
script is undesirable, but I don't think this is one of them.

If there's a better way to package Asunder, I'm happy to do it.
However, I haven't heard of any concrete alternatives, or any concrete
explanations of why a wrapper is undesirable.  Until then, I think using
a wrapper like this to package components like Asunder is the best way.

-- 
Chris