<rekado_>getting something packaged for Guix is clearer and safer than just building it in a polluted environment.
<rekado_>about solfege and its dependency on pygtk: should I proceed with providing wrappers for all Python executables so that the PYTHONPATH is set to include the pygtk directory or is there a better way to do this?
<rekado_>without doing anything I get an import error when running "solfege".
<rekado_>as pygtk is just a regular input it does not appear in ~/.guix-profile/lib and I don't want to have to tell users to manually add the long pygtk store directory to their PYTHONPATH.
<mark_weaver>civodul: you wrote before your vacation that builds were done with a UTF-8 localed before the locales were removed from glibc, but when I looked, I didn't see anything that would have set LANG or LC_ALL or would have called 'set-locale' in the guile builders. was I missing something?
<mark_weaver>according to the glibc manual, LANG and LC_ALL are effectively equivalent as long as no other LC_* variables are set. if they are, then they take precedence over LANG but LC_ALL takes precedence over all.
<civodul>ah ok, i wasn't sure about the difference either
<civodul>just a vague feeling that LC_ALL was "stronger" ;-)
<mark_weaver>anyway, I guess these environment variables need to be set in the derivations themselves, rather than in a phase, so that the guile build process will pick them up, but I'm not sure how best to deal with the bootstrapping issues.
<civodul>exactly, using the #:environment-variables or #:env-vars (?) parameter
<rekado_>oh, I think I know why it didn't work before: I tried to remove inputs from (package-inputs (package-with-python2 scikit-learn)), but (package-inputs ...) does not return the inputs of the inputs.
<mark_weaver>civodul: regarding setting LANG and GUILE_INSTALL_LOCALE variables in most derivations, two questions: (1) where should this be done (e.g. how generally), and (2) how should we deal with the bootstrapping issues? if you'd prefer to just make the changes yourself rather than talk me through it, that's fine too :)
<davexunit>Digit: that's why our official slogan is "Have it your way"
<davexunit>I don't think a large fast food burger chain has used that...
<Digit>sounds very pro-choice. snapping at gentoo's useflag heels yet? or is that further down the road still?
<davexunit>Digit: there was a conversation about useflags on the mailing list. We don't think it's particulary useful for us.
<davexunit>since packages are first-class Scheme objects
<Digit>yeah, i've yet to get into that way of thinking about it. ... started watching the mit computer science lectures on lisp, inspired in no small part by guix (and it being overdue, having been an emacs user for at least a couple years now).
<mark_weaver>on the one hand, using a private git branch, it's easy to keep arbitrary local patches to any part of guix, and to easily merge upstream into your branch or rebase your branch on top of upstream master.
<mark_weaver>and this is strictly more flexible and powerful than use flags.
<mark_weaver>on the other hand, it would be possible to facilitate global changes by making our package descriptions honor those global flags.
<mark_weaver>well, I can't really continue this now, but the main thing is that it would multiply the number of combinations to test by a rather large factor, and our community is as yet too small to effectively test so many combinations.
<mark_weaver>and our build farm is not nearly large enough to build pre-compiled binaries for all of those possible combinations.