On guix days in the guix home discussion the following observations were
made:
1. It is rare that guix home import does the right thing (it is usually
removing some startup file customizations, does not seem to arrange to pick
up profiles, not even its own). Either we should improve it, or document
that it only gives a skeleton configuration and add some guidance on the
steps needed to get a working one.
2. The user default profile and the home package profile being separate is
causing some issues. It might be enough to document all the special
profiles somewhere (which as of now include at least system profile, user
profile, pull profile and home profile), but we can also think about a bit
more general solution, along the lines of a home service that ensures that
a given profile matches the supplied manifest, and have variables for the
special profiles. (These could then provide extensions to the shell
services which could arrange to pick them up)
3. Sometime on home reconfigure the shell prompt customizations seem to get
lost. Sourcing the shell startup file fixes it. I will have to look into
this more to file a proper bug report.
4. Creating a guix development environment service would be beneficial, to
showcase the possibilities and to simplify onboarding. On top of there
could be an additional service that adds emacs integration to this
development environment.
5. There was a recommendation to relax the expectations on the home
services merged. Right now a lot of people are just writing services for
private use. Most probably such a single usecase service would already be
beneficial to multiple people. The idea is the following: make it easy for
an initial home service to be merged. (Example: do not ask to implement
options that the submitter is not using). Then take care that if there is
an addition to the service that it really gets merged with what we already
have. This needs a bit of up front design, we have to make sure that the
services can be extended while maintaining backwards compatibility.