IRC channel logs
2026-09-18.log
back to list of logs
<attila_lendvai>ryanprior, the way it works with python is that it directly uses the variable called version, which works because it's the API of the package constructor (the earlier fields are lexical variables in the initializers of the later fields) <ryanprior>I did read into how Python did it and noticed that. <ryanprior>I did a lot of grepping before I came to bug the irc QQ of course I'm sure I missed many things <attila_lendvai>ryanprior, maybe the proper fix is to smarten up the fennel package? <ryanprior>attila_lendvai: perhaps, what would that mean? <attila_lendvai>ryanprior, maybe introduce the equivalent of GUIX_PYTHONPATH for fennel? but i'm just wild guessing here. <attila_lendvai>from the little i know, FENNEL_PATH seems to be pretty much the equivalent of PYTHONPATH <ryanprior>I discussed that with upstream and they strongly discouraged me. They said Fennel tooling will assume that exactly one tool (Guix in this case) will construct the path, and that it will be called FENNEL_PATH. <ryanprior>My understanding of why we have GUIX_PYTHONPATH is because we want Guix to play nicely with other tools that may set PYTHONPATH, and fennel upstream are of the opinion that this is not a use case worth supporting <attila_lendvai>ryanprior, well, then without the GUIX_ prefix... what i mean is that the fennel package should be responsible for setting up FENNEL_PATH, not the gazillion fennel-foo libraries <ryanprior>how does the fennel package know what all fennel libs you're going to install <ryanprior>does it somehow collect symlinks to them into a directory? I don't know how to set that up <ryanprior>because I would be absolutely fine with that as a solution <attila_lendvai>ryanprior, i don't understand that either. just a hint: what i know is that you need to also include the python package into a guix shell pythin-this python-that invocation for this to work. IOW the profile gets constructed, probably some paths populated, and then the python package is the one that sets the env variable. <attila_lendvai>ryanprior, but i think it has reached a point where it would be worth writing a mail to guix-devel, because there are several people who undestand this, they are just not around here now <ryanprior>I have a much better idea what to ask guix-devel about after the input I've got here, thanks attila_lendvai, lechner and others :) <lechner>ryanprior: the package knows from the inputs <ryanprior>I can't connect those code locations you linked through to what I'm trying to figure out. I sense you must intend me to learn something about the relationship between package inputs and search paths? But neither of those code snippets seem to deal with search paths at all, so it went over my head <attila_lendvai>what is gnome-session-shepherd, and why is it developed somewhat outside the guix umbrella? <lechner>ryanprior: my point was simply, and mundanely, that the package inputs are available to the build system <ryanprior>I dunno why you offered that then lechner, that was never in question <ryanprior>I have figured out some interesting things though. there is an implicit relationship between packages in a profile. if any of those packages declares a search path spec, the spec is applies to all packages in the profile to calculate the final value. This is key <ryanprior>if the `fennel' package declares a search pach spec for FENNEL_PATH targeting a specific directory, then when a profile is being built that directory (relative to each package in the profile) will be scanned for fennel files and they are all gathered up to calculate the final FENNEL_PATH <ryanprior>the individual fennel libs do not have to set a search path at all, it is sufficient to install into the (relative) directory in the search path spec <ryanprior>so my frustration with building appropriate search paths in the fennel libs was downstream of my ignorance about the implicit search path spec-mediated connection between packages in a profile <dlowe>I had a similarly tough time trying to wrangle tcl packages. I never really did manage. <tomenzgg>I don't know if anyone's run into anything like this, before, but I'm trying to run mpDris2 with notifications; it checks if there's a notification service running, first, via DBus. I've got Dunst running and that works just fine and I can find "org.freedesktop.Notifications" via DBus just fine <tomenzgg>Yet mpDris2 just seemingly cannot; I looked up its code and the impacted section doesn't look that complicated. It's using dbus.service which the package has as a dependency and it's checking via calling .get_name_owner("org.freedesktop.Notifications") on a dbus.SessionBus() <tomenzgg>I opened a shell with guix shell -D mpDris2 and ran python and tried out that very code and got back a response so it seems even the python code is working; I can't tell what could possibly be causing it to not detect Dunst but figured I'd ask if anyone had any possible idea <podiki>apteryx: commit 9ab31b265cd978019db0877234cd6c624f9076d1 broke mangohud, seems to need implot 0.16 built against imgui-1.91 <podiki>apteryx: can test with "guix shell vulkan-tools mangohud vulkan-loader -- mangohud vkcube" <podiki>apteryx: or implot 0.17 but with imgui 1.91 (i would guess mangohud needs matching imgui libraries that are linked) <apteryx>is there a test suite we could enable for mangohud? <apteryx>do we have an example of a vulkan application running in the guix build environment (e.g., in a check phase?)