Hey Alex, Alex ter Weele <[email protected]> skribis:
> Attached is a manifest file which allows a user to write a > shepherd-service like the following: > > (define redshift-service > (shepherd-service > (provision '(redshift)) > (modules `((gnu packages xdisorg) > ,@%default-modules)) > (start #~(make-forkexec-constructor > (list (string-append #$redshift "/bin/redshift") > "-l" "50:4"))))) > > And transform it into a package: > > (services->package (list redshift-service)) > > This allows it to be included in a user's profile. This unites the > definition of a service with its dependencies (redshift, in the example > above). A user would not have to install a package just to use it as a > service, nor would they have to hand-write a Shepherd configuration > file. Indeed, that’s a neat hack! And it ties software and service deployment, which is great. > ;; the next two are copied from (gnu services shepherd) because: > > ;; * (gnu services shepherd)'s version of shepherd-configuration-file > ;; is for the pid1 shepherd and has some stuff like fallback-to-REPL > ;; that is not necessary for user services. > > ;; * (gnu services shepherd) doesn't export > ;; shepherd-configuration-file. That we can fix. :-) Would it be enough for you? I don’t think the first item is a showstopper, is it? > (define (services->package services) > "Yield a package for SERVICES by making them into a shepherd > configuration file via scheme-file." This makes me think that perhaps we should generalize profile, and allow non-package objects in there—it doesn’t feel right to define a <package> for something that’s conceptually not a package at all. But then that leads to issues, like what should ‘guix package -u’ do? How should ~/.guix-profile/manifest represent these non-package things? Should we add ‘guix package --install-service’ or similar? (Well, that may be overboard…) It would be nice to think about whether/how we could make this part of Guix proper. Thanks! Ludo’.
