Hi Maxime,

Thank you for the review! I attached a new patch set. 

I reverted to Bonface's original idea of having lilypond only as a native input in the package definition.

I prefer this solution in order to solve the problem since it follows upstream's instructions of installing lilypond separately (https://abjad.github.io/first_steps/linux.html), doesn't pollute a guix user's profile with lilypond as you mentioned, and seems a bit cleaner since I don't have to touch the python sources in order to make them find the lilypond input.

If the user wants to produce a pdf then they can just include lilypond in their profile.

What do you think?

best regards,

jgart

ps

This caused me to have to add lilypond as a native-input to abjad-ext-rmakers (47816), abjad-ext-nauert (47817), and abjad-ext-ipython (47818) since those where building successfully before because they had abjad as a propagated input and abjad had lilypond as a propagated input. The above mentioned packages require lilypond for the tests.




April 16, 2021 6:12 AM, "Maxime Devos" <maximedevos@telenet.be> wrote:

> On Fri, 2021-04-16 at 04:57 +0000, jgart via Guix-patches via wrote:
> 
>> Hi Guix,
>> 
>> Below are some improvements to the python-abjad package that was merged the other day.
>> 
>> I changed the name to abjad, moved some inputs into their correct place,
> 
> Please move 'lilypond' from propagated-inputs to 'inputs', if sanely possible!
> This avoids polluting the profile with packages the user did not
> explicitely request. Of course, abjad still somehow has to find
> lilypond, so you might need to replace "lilypond" with
> 
> (string-append (assoc-ref inputs "lilypond") "/bin/lilypond")
> 
> somewhere in python-abjad's source code. You can use substitute*
> for that.
> 
> Greetings,
> Maxime.