Hi Danny,

> Or should we just expect the user to put a (shepherd with fix)
> invocation into their HOME startup scripts like .xinitrc ?

I wrote a first draft of user services a month ago. The idea here is
that guix user -r user-manifest.scm generates a script that lauches a
user shepherd.

For instance with the following user-manifest.scm :

--8<---------------cut here---------------start------------->8---
(define (redshift-service config)
  (list (shepherd-service
         (documentation "Run redshift.")
         (provision '(redshift-test))
         (requirement '())
         (start #~(make-forkexec-constructor
                   (list (string-append #$redshift "/bin/redshift")
                         "-l" "48:2")))
         (stop  #~(make-kill-destructor)))))

(define redshift-service-type
  (service-type
   (name 'test-user)
   (extensions
    (list
     (service-extension shepherd-user-service-type
                        test-shepherd-service)))))

(user-configuration
 (services (list (service redshift-service-type #f))))
--8<---------------cut here---------------end--------------->8---

I get a script that lauches shepherd himself starting redshift.

The plan here was to add a symlink, (don't know where !), pointing to
the last generated shepherd script, and have the user start shepherd by
executing the script pointed by the symlink in his .xinitrc for
instance.

> Note that if we did that there's some session-specific stuff in the session's environment that shepherd will inherit.  Probably not that bad if invoked early enough.

Starting shepherd there ensures to have DISPLAY, XAUTHORITY and other
variables that user services may use (like redshift).

I attached my draft patch.

Thanks,

Mathieu