bug#70553: Packages built via gexp but not "installed" are not visible in containerized environments

[Richard Sent]

Hi Guix!

Consider a home environment with the following configuration:

--8<---------------cut here---------------start------------->8---
(use-modules (guix gexp)
             (gnu home)
             (gnu home services shells)
             (gnu services)
             (gnu packages dns))

(home-environment
 ;; (packages `((,isc-bind "utils")))
 (services
  (list   
   (service home-bash-service-type
            (home-bash-configuration
             (aliases
              `(;; Add other aliases here
                ,@(let ((dig (file-append (gexp-input isc-bind "utils") 
"/bin/dig")))
                    `(("wanip"  . ,#~(string-append #$dig " 
@resolver4.opendns.com myip.opendns.com +short"))
                      ("wanip4" . ,#~(string-append #$dig " 
@resolver4.opendns.com myip.opendns.com +short -4"))
                      ("wanip6" . ,#~(string-append #$dig " 
@resolver1.ipv6-sandbox.opendns.com AAAA myip.opendns.com +short -6")))))))))))
--8<---------------cut here---------------end--------------->8---

When starting a container with this home environment via `$ guix home
container home.scm`, `wanip` will be successfully aliased to
`/gnu/store/...-bind-<version>-utils/bin/dig` and that package will be
built by the daemon.

However, because the container only sees a subset of /gnu/store that
contains packages registered in the profile, that path will not be
present in the container. This can be confirmed by uncommenting the
(packages) field.

I don't know the best way to resolve this, but in my opinion the fact
that Guix lets you combine package "installation" and usage in a gexp is
a great feature. This is definitely cleaner than needing to create an
entire custom service that extends both the home profile service and
home bash service. Especially if this is done multiple times. I also
think this is better than adding isc-bind to the profile and hardcoding
"dig" in .bashrc.

It would be nice if Guix was smart enough to register that store path as
belonging to the home environment and keep it visible to the container
so the behavior could be consistent between `$ guix home reconfigure`
and `$ guix home container`.

Perhaps there's a better way to determine the /gnu/store subset that
should be visible to containers besides just reading the environmnet's
profile.

I expect this crops up in a lot more places than just home environments
and home bash service. I'd hope for a more generalized solution
that solves this problem across multiple services, not specifically
home-bash-service.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.