Re: [PATCH 1/2] gnu: Add python-mpd2

[Leo Famulari <leo@famulari.name>]

On Thu, Feb 18, 2016 at 10:08:12PM +0000, Christopher Baines wrote:
> On 18/02/16 22:00, Leo Famulari wrote:
> > On Thu, Feb 18, 2016 at 09:26:53PM +0000, Christopher Baines wrote:
> >> * gnu/packages/python.scm (python-mpd2): New variable
> >> * gnu/packages/python.scm Import lgpl3.
> > 
> > I actually have a patch for this in a WIP tree (attached). Based on the
> > differences, and the fact that I have already made the changes requested
> > below, I think my version of the patch should be used. My patch also
> > adds a python-2 version; when possible, it's preferred to add both
> > versions.
> > 
> > What do you think?
> 
> That's fine by me.
> 
> >> +    (build-system python-build-system)
> >> +    (arguments
> >> +     `(#:phases
> >> +       (alist-replace
> >> +        'check
> >> +        (lambda _ (zero? (system* "python" "mpd_test.py")))
> >> +        %standard-phases)))
> >> +    (inputs
> >> +      `(("python-setuptools" ,python-setuptools)
> >> +        ("python-mock" ,python-mock)
> >> +        ("python-unittest2" ,python-unittest2)))
> > 
> > I don't believe that unittest2 is needed. I can build both
> > python-variants without it.
> 
> From looking at the source, I think its only needed for running the
> tests with python2.6 [1].
> 
> 1:
> https://github.com/Mic92/python-mpd2/blob/6818984462552dbc7ca85d014f5cf9a8a1e81aec/mpd_test.py#L14
> 
> > Setuptools is only needed for the python2-variant.
> > 
> > And, I think mock is only needed at build-time, so it would be a
> > native-input.
> 
> I though native inputs had something to do with architectures, which I
> guess won't matter here, so why is it not just an input?

The "native" part refers to the architecture of the build machine, which
is important when cross-compiling.

A side benefit is that end users shouldn't have to download
native-inputs when substituting. In some cases, that can save a lot of
bandwidth. So, we make build-time-only dependencies native-inputs. In
practice, I've seen packages end up with references to native-inputs in
their output, but that's not optimal.

Semi-relevant discussion of the problems of propagated-inputs:
http://lists.gnu.org/archive/html/guix-devel/2016-02/msg00810.html