[bug#44170] [PATCH] gnu: Correct Inkscape extension dependencies

[Ekaitz Zarraga <ekaitz@elenq.tech>]

Hi,

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, October 24, 2020 9:55 PM, Christopher Baines <mail@cbaines.net> wrote:

>
>
> Ekaitz Zarragaekaitz@elenq.tech writes:
>
> > Updated with file-name thanks to Christopher Baines' help.
> > Guix lint is not complaining anymore about the file name.
> > (it complains about the version but it's because of a bad naming system
> > upstream)
>
> I've had a proper look at this patch now. In general, especially for
> adding new packages, do one thing per commit. I've split out the
> addition of python-scour in to it's own commit and pushed that now.

Thanks.

I'll take that in account in the future.

> I had some thoughts on the inkscape changes though.

I had some too, thanks for elaborating.

> >
> > -                     (,(string-append python "/bin:")))))
>
> The : after /bin is unnecessary.

I copied all this from Kicad's package because it's a software
that has a similar python plugin style.

> Also, it looks like python-wrapper is already referenced lots in the
> output, did you have a specific reason why wrapping inkscape with the
> PATH was useful?

Not really.
I just copied it from kicad and followed the discussion at guix-devel...
I thought it was necessary but watching what python-wrapper does it's
probably not necessary. I'll try it without the PATH and remove it if
it's not useful.

I'll compare with kicad's package too, because they are very similar
so they should have some relation on this too.


> >
> >
>
> So, before python-wrapper was a native-input, and you've added some
> Python packages as native inputs.
>
> The distinction for inkscape between an input and a native input is
> mostly academic at this point, because the meson build system doesn't
> support cross builds.
>
> However, inkscape already uses references python-wrapper in its output,
> so it should probably be an input. With this change, you're also setting
> out that inkscape should be able to use these Python libraries at
> runtime, hence they should be inputs (matching the architecture you're
> building for), rather than native inputs (matching the architecture
> you're building on).
>
> Does that make sense?

Something obviously doesn't. :)
In my understanding, python should be an `input` but it was already in
`native-inputs`, I don't know why. So I considered all the rest of the
python-related packages should be in the same block.

If I did this package I would add python-* and python itself as inputs.

So, I follow your explanation and it's what I understood, but I don't
get why were python related things in native-inputs before. That
confused me.

I'll move those to inputs. Could you explain or find a reason why python
wasn't an input before? is it just an error?

>
> Thanks,
>
> Chris


Thank you for your time and for the explanations. Really helpful.

I'll follow up with the updated patch soonish. Only with the Inkscape
part.

Best,
Ekaitz