Ekaitz Zarraga <ekaitz@elenq.tech> writes:
Toggle quote (5 lines)
>> 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.
That's fine, it's also unnecessary there :)
If you pull the generated shell out of the bin/kicad or bin/inkscapefile, and play around with it in a shell, you should see something like:
→ export PATH="/gnu/store/11l2qmzfgsp7k345mv6x1vn64q8330kw-python-wrapper-3.8.2/bin:${PATH:+:}$PATH"
→ echo $PATH/gnu/store/11l2qmzfgsp7k345mv6x1vn64q8330kw-python-wrapper-3.8.2/bin::/gnu/store/hgh67ilwsbx6v2irc7vgrnv354cv4h8a-profile/bin
Note the double colon, I don't think it's a problem in terms offunctionality, but just in case someone copies this from inkscape as anexample, it would be good not to do the same here.
Note, there's no need to fix this in kicad. If you do want to, I'dsubmit a separate commit under a seperate bug.
Toggle quote (13 lines)
>> 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.
Sounds good, it's possible something, or plugins expect the PATH to havepython on it, if so, that's fine, but it would be good to note thereason in a comment. Otherwise, this bit can be removed.
Toggle quote (30 lines)
>> 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?
Well, error is a strong word, in this case, given the build systemdoesn't support building for a non-native architecture, it's sort of anon-issue. But I would view it as something you're fixing in addition tothe changes you're making.
It didn't (and still doesn't to some extent) matter that the Pythonstuff was/is in native-inputs, because cross building this package isimpossible because of the build system.
However, in case the build system changes to support this, to beconsistent with other package definitions, and to be consistent with thegeneral rule that you don't reference native-inputs from the outputs (atleast I think that's a rule or at least strong convention), having thePython stuff in inputs is better. Even if the package builds just thesame.
Toggle quote (5 lines)
> 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.
You're welcome :) I look forward to it.
Thanks,
Chris