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.
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.
-- Ian
