Hi Ian, Ian Eure <[email protected]> writes:
> Hi Maxim, > > Maxim Cournoyer <[email protected]> writes: > >> Hi Ian, >> >> I haven't read the code you wrote, so my suggestion may not be to >> the >> point, but have you considered "generating the profile" as part of >> the >> service? > > This is more or less what I was struggling to do. > >> I.e., the collectd-configuration could have an 'extensions' field or >> similar that would accept a list-of-file-likes type that would be >> python >> packages, and you'd compute the GUIX_PYTHONPATH in the supporting >> service code and write this in its configuration? > > The issue with this approach is that computing GUIX_PYTHONPATH is > non-trivial. Python abstracts its dependencies -- meaning you have > "import foo" in the code, and the specific "foo" is dynamic based on > the contents of sys.path (instead of directloading a store path > computed ahead of time) -- so all dependencies have to be > propagated-inputs. Computing GUIX_PYTHONPATH means a recursive walk > over the inputs of every package, accumulating those packages and > their propagated-inputs, otherwise everything breaks when you add a > package that needs any Python library. > > And doing that is basically reimplementing what profiles already do. > That feels like a mistake. Agreed; it's not impossible but it's redundant. That's basically what I did in the luanti-service-type to set the required variables, and I also pondered whether a profile could be used instead. > In any case, Rutherer helped me solve this. Creating the profile in > the service code, then ungexping it in the serializer will implicitly > build the profile, allowing its GUIX_PYTHONPATH to be extracted and > dropped in the configuration file. > > If you want to take a look at the PR, I’d still appreciate feedback, > particularly around the documentation. Nice, I'll try taking a look, since I'm curious about the solution. Thanks for sharing! -- Thanks, Maxim
