guix shell --container from Shepherd to run a service
dear Guix,
my ultimate goal is to run Home Assistant (a python based service) from
Shepherd.
packaging it seems to be too much effort, so i looked into running it in a
`guix shell --container`. it works fine when done from the terminal:
$ su - hass
$ guix shell --manifest=manifest.scm --container --emulate-fhs --network
--share=/srv/hass
$ cd /srv/hass && source bin/activate && LD_LIBRARY_PATH=/lib:/lib64 hass 2>&1
| tee /var/log/home-assistant.log
(specifications->manifest
'("python"
"python-virtualenv"
"python-pytzdata"
"autoconf"
"openssl"
"libxml2"
"libxslt"
"libjpeg"
"libffi"
"eudev"
"zlib"
"pkg-config"
"ffmpeg"
"gcc-toolchain"
"git"
))
now, i've converted this to a Shepherd service like this:
(simple-service
'home-assistant
shepherd-root-service-type
(list
(shepherd-service
(requirement '(file-systems networking guix-daemon))
(provision '(home-assistant))
(documentation "")
;; TODO herd stop doesn't work
(start
#~(lambda _
(fork+exec-command
(list #$(file-append guix "/bin/guix")
"shell"
"--manifest=manifest.scm"
"--container"
"--emulate-fhs"
"--network"
"--share=/srv/hass"
"--"
#$(file-append bash "/bin/bash")
"-c" "cd /srv/hass && source bin/activate &&
LD_LIBRARY_PATH=/lib:/lib64 hass")
#:log-file "/var/log/home-assistant.log"
#:user '#$(user-account-name *hass-user*)
#:group '#$(user-account-group *hass-user*)
#:supplementary-groups
'#$(user-account-supplementary-groups *hass-user*)
#:environment-variables
(list (string-append "HOME=/home/"
#$(user-account-name *hass-user*)
but this errors out:
guix shell: error: mkdir: Permission denied:
"/tmp/guix-directory.sfpIhA/real-root"
should this work, or am i holding it wrong?
or should it be done some other way? any examples around?
if it should work, then any hints on what to look at for a fix? grepping for
'real-root' brings up MOUNT-FILE-SYSTEMS in linux-container.scm, but i couldn't
find anything obviously broken there.
sidenote: debugging this would be a lot easier if the error wasn't reduced to
the above line, but instead a general error handler printed a backtrace.
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“When men yield up the privilege of thinking, the last shadow of liberty quits
the horizon.”
— Thomas Paine (1737–1809)
Re: guix shell --container from Shepherd to run a service
> I have no idea it this is the cause, but the immediate difference I see > between the terminal (working) and shepherd service (not working) is the > current working directory. In the former case it would be ~hass, in the > latter case it would be /. Guix shell defaults to making CWD available > in the container, so it in the service case (I am guessing) mounts / > onto / of the containers which might mess up some permissions. > > You might try setting #:directory if you need the $HOME accessible, or > pass --no-cwd if you do not. excellent tips Tomas, thank you! i think the essential part was specifying #:directory "/srv/hass". FTR, this is what i ended up with: (simple-service 'home-assistant shepherd-root-service-type (list (shepherd-service (requirement '(file-systems networking guix-daemon)) (provision '(home-assistant)) (documentation "") ;; TODO herd stop doesn't work. it leaves the process ;; running without any errors. (start #~(lambda _ (fork+exec-command (list #$(file-append guix "/bin/guix") "shell" "--manifest=/srv/hass/manifest.scm" "--container" "--emulate-fhs" "--network" "--share=/srv/hass" "--no-cwd" "--expose=/gnu" "--expose=/run/current-system" "--" #$(file-append bash "/bin/bash") "-c" "cd /srv/hass && source bin/activate && LD_LIBRARY_PATH=/lib:/lib64 hass --config=/srv/hass/config") #:log-file "/var/log/home-assistant.log" #:user '#$(user-account-name *hass-user*) #:group '#$(user-account-group *hass-user*) #:directory "/srv/hass" #:supplementary-groups '#$(user-account-supplementary-groups *hass-user*) #:environment-variables (list (string-append "HOME=/home/" #$(user-account-name *hass-user*) notice that --expose=/gnu was needed, and possibly --expose=/run/current-system, too, but i didn't double check every change. this way the `guix shell` call will get the versions from the hass user's pull state; i.e. i can independently decide when to upgrade the guix environment of the hass user and process. it's a relatively painless escape hatch to run even a non-trivial service without packaging the app and writing the necessary service code. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “An extreme optimist is a man who believes that humanity will probably survive even if it doesn't take his advice.” — John McCarthy (1927–2011), father of Lisp
Re: guix pull from private ssh server fails
Hi Guix, Christoph, I can confirm that the patch Christoph links upthread (https://issues.guix.gnu.org/77154) fixes the problem I ran into. Test steps: * Create custom libssh2-1.11.1 package, that inherits Guix channel libssh2 and applies Christoph's fixes. * Build and install the libssh2-1.11.1 package. * Install transformed libgit2 package to link against libss2-1.11-1 with the "--with-input=libssh2=libssh2@1.11.1" option ** I used git2 command line previously to reproduce / test the issue. This fixed that particular error, although I ran into another one. * Install transformed guix package to link against libssh2-1.11.1 * guix pull worked Cheers, Matthew Todd matt...@zerobitcoder.net
Re: guix shell --container from Shepherd to run a service
Hello Attila,
Attila Lendvai writes:
> dear Guix,
>
> my ultimate goal is to run Home Assistant (a python based service) from
> Shepherd.
>
> packaging it seems to be too much effort, so i looked into running it in a
> `guix shell --container`. it works fine when done from the terminal:
>
> $ su - hass
> $ guix shell --manifest=manifest.scm --container --emulate-fhs --network
> --share=/srv/hass
> $ cd /srv/hass && source bin/activate && LD_LIBRARY_PATH=/lib:/lib64 hass
> 2>&1 | tee /var/log/home-assistant.log
>
> (specifications->manifest
> '("python"
> "python-virtualenv"
> "python-pytzdata"
> "autoconf"
> "openssl"
> "libxml2"
> "libxslt"
> "libjpeg"
> "libffi"
> "eudev"
> "zlib"
> "pkg-config"
> "ffmpeg"
> "gcc-toolchain"
>
> "git"
> ))
>
> now, i've converted this to a Shepherd service like this:
>
> (simple-service
> 'home-assistant
> shepherd-root-service-type
> (list
> (shepherd-service
>(requirement '(file-systems networking guix-daemon))
>(provision '(home-assistant))
>(documentation "")
>;; TODO herd stop doesn't work
>(start
> #~(lambda _
> (fork+exec-command
> (list #$(file-append guix "/bin/guix")
>"shell"
>"--manifest=manifest.scm"
>"--container"
>"--emulate-fhs"
>"--network"
>"--share=/srv/hass"
>"--"
>#$(file-append bash "/bin/bash")
>"-c" "cd /srv/hass && source bin/activate &&
> LD_LIBRARY_PATH=/lib:/lib64 hass")
> #:log-file "/var/log/home-assistant.log"
> #:user '#$(user-account-name *hass-user*)
> #:group '#$(user-account-group *hass-user*)
> #:supplementary-groups
> '#$(user-account-supplementary-groups *hass-user*)
> #:environment-variables
> (list (string-append "HOME=/home/"
> #$(user-account-name *hass-user*)
>
>
> but this errors out:
>
> guix shell: error: mkdir: Permission denied:
> "/tmp/guix-directory.sfpIhA/real-root"
>
> should this work, or am i holding it wrong?
>
> or should it be done some other way? any examples around?
>
> if it should work, then any hints on what to look at for a fix? grepping for
> 'real-root' brings up MOUNT-FILE-SYSTEMS in linux-container.scm, but i
> couldn't find anything obviously broken there.
>
> sidenote: debugging this would be a lot easier if the error wasn't
> reduced to the above line, but instead a general error handler printed
> a backtrace.
I have no idea it this is the cause, but the immediate difference I see
between the terminal (working) and shepherd service (not working) is the
current working directory. In the former case it would be ~hass, in the
latter case it would be /. Guix shell defaults to making CWD available
in the container, so it in the service case (I am guessing) mounts /
onto / of the containers which might mess up some permissions.
You might try setting #:directory if you need the $HOME accessible, or
pass --no-cwd if you do not.
I am unsure this will solve your problem, but I hope it at least helps.
Have a nice day,
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Re: Emacs dependent package input question
On 2025-04-05 16:55, Ian Eure wrote: >> I'd argue sometimes it's indeed the better solution, especially >> when >> the core of the package needs the binary to work properly, not >> when it's >> an additional option or feature. I'll refer to that as >> "essential >> binary" in the rest. > > I appreciate this line of thinking, but suspect that whether a > binary is essential or not depends on the user’s usecase, which is > unknowable at package build time. For a user using EMMS to play > MP3s, flac isn’t essential, and mpg321 is; for someone using it to > play FLACs, the inverse is true. > >> (This is the case where not having the binary is absurd because >> it >> renders the emacs package unusable). > > I think it’s important to distinguish between "unusable" and "not > usable unless the user takes some action." In those cases, maybe we could have -minimal variants? >> I agree this is nice, but maybe it's enough to do that in Emacs >> packages >> themselves (ensuring they suggest the missing binary when it's >> not >> found) rather than in Guix Home itself. > > I also like this idea; do you have an idea what an implementation > for that would look like? Presumably upstream package authors > wouldn’t want Guix-specific stuff in packages that need to work on > any OS/distro. Indeed, I don't mean plainly writing "Guix profile" in Emacs packages, but ensuring for instance that we have a proper error message explaining that the package is not in the PATH. I guess something like "Unable to find xxx, ensure it is installed on your system." is clear enough. A recent example that happened to me (not a binary though but a guix-related bug): https://github.com/anticomputer/age.el/issues/15 was fixed with https://github.com/anticomputer/age.el/pull/16/commits/a1c9d0a7911e603e6574daf1ee6d602d1e932842 Not writing "Guix" anywhere, but it makes it clear that something is missing on the system. -- Best regards, Nicolas Graves
Re: guix shell --container from Shepherd to run a service
Hi Attila
> dear Guix,
>
> my ultimate goal is to run Home Assistant (a python based service)
> from Shepherd.
I have a not yet running attempt of home assistant packaged, maybe you
would like to have a stab at it?
> packaging it seems to be too much effort, so i looked into running it in a
> `guix shell --container`. it works fine when done from the terminal:
>
> $ su - hass
> $ guix shell --manifest=manifest.scm --container --emulate-fhs --network
> --share=/srv/hass
> $ cd /srv/hass && source bin/activate && LD_LIBRARY_PATH=/lib:/lib64 hass
> 2>&1 | tee /var/log/home-assistant.log
>
> (specifications->manifest
> '("python"
> "python-virtualenv"
> "python-pytzdata"
> "autoconf"
> "openssl"
> "libxml2"
> "libxslt"
> "libjpeg"
> "libffi"
> "eudev"
> "zlib"
> "pkg-config"
> "ffmpeg"
> "gcc-toolchain"
>
> "git"
> ))
>
> now, i've converted this to a Shepherd service like this:
>
> (simple-service
> 'home-assistant
> shepherd-root-service-type
> (list
> (shepherd-service
>(requirement '(file-systems networking guix-daemon))
>(provision '(home-assistant))
>(documentation "")
>;; TODO herd stop doesn't work
>(start
> #~(lambda _
> (fork+exec-command
> (list #$(file-append guix "/bin/guix")
>"shell"
>"--manifest=manifest.scm"
>"--container"
>"--emulate-fhs"
>"--network"
>"--share=/srv/hass"
>"--"
>#$(file-append bash "/bin/bash")
>"-c" "cd /srv/hass && source bin/activate &&
> LD_LIBRARY_PATH=/lib:/lib64 hass")
> #:log-file "/var/log/home-assistant.log"
> #:user '#$(user-account-name *hass-user*)
> #:group '#$(user-account-group *hass-user*)
> #:supplementary-groups
> '#$(user-account-supplementary-groups *hass-user*)
> #:environment-variables
> (list (string-append "HOME=/home/"
> #$(user-account-name *hass-user*)
>
>
> but this errors out:
>
> guix shell: error: mkdir: Permission denied:
> "/tmp/guix-directory.sfpIhA/real-root"
>
> should this work, or am i holding it wrong?
>
> or should it be done some other way? any examples around?
>
> if it should work, then any hints on what to look at for a fix? grepping for
> 'real-root' brings up MOUNT-FILE-SYSTEMS in linux-container.scm, but i
> couldn't find anything obviously broken there.
>
> sidenote: debugging this would be a lot easier if the error wasn't reduced to
> the above line, but instead a general error handler printed a backtrace.
>
> --
> • attila lendvai
> • PGP: 963F 5D5F 45C7 DFCD 0A39
> --
> “When men yield up the privilege of thinking, the last shadow of liberty
> quits the horizon.”
> — Thomas Paine (1737–1809)
Re: Emacs dependent package input question
Liliana Marie Prikler writes:
> Am Samstag, dem 05.04.2025 um 09:38 -0700 schrieb Ian Eure:
>> Hi Guixers,
>>
>> I’ve seen a few patches for Emacs packages lately which have the
>> form:
>>
>> (package emacs-whatever
>> (name "emacs-whatever")
>> (description "Emacs interface for Whatever")
>> (inputs (list whatever))
>> (arguments
>> (list
>> #:phases
>> (modify-phases %standard-phases
>> (add-after 'unpack 'set-whatever-path
>> (lambda (#:key inputs #:allow-other-keys)
>> (emacs-substitute-variables "whatever.el"
>> ("emacs-whatever-program"
>> (search-inputs-file inputs
>> "/bin/whatever")
> Side note: the ordering of fields here looks rather displeasing.
>
>> ...and looking in emacs-xyz.scm, many packages do this. I
>> understand why this pattern exists -- making the inferior an input
>> means that installing the Emacs package Just Works -- but it also
>> means increased disk consumption and somewhat less user
>> flexibility.
>>
>> On the flexibility side, it means that if you install
>> emacs-whatever and my-personal-whatever-fork, emacs-whatever will
>> continue using the stock whatever, not your fork; making this work
>> requires transforming emacs-whatever to replace the input. I
>> think that because this behavior is so different from how most
>> other operating systems work, it’s surprising, and the solution
>> isn’t obvious.
> You obviously can still customize it to use a PATH lookup. You are
> wasting disk space if you do so. Alternatively, input rewriting such
> as the --with-input command line flag replace whatever with your-
> personal-whatever-fork and thus do exactly what you want.
>
>> […]
>> I’m not sure how to do that, though. I can think of a few
>> options:
>>
>> a) Leave it as is. Don’t love it, but if there’s concensus that
>> this is the right way, then okay.
>>
>> b) Make packages that align better with specific usecases,
>> ex. emacs-emacsql-sqlite, -mysql, etc. This feels fraught to me,
>> and I don’t think it works if you get emacs-emacsql-sqlite as an
>> input to some other emacs-* package, but want emacs-emacsql-mysql
>> as a user. Perhaps metapackages which only exist to combine
>> dependencies would make this a workable approach.
>>
>> c) Don’t set them at all, and use the same $PATH late binding as
>> is typical of other Emacs setups. This would mean that
>> installing Emacs packages wouldn’t Just Work, and users would
>> have to install the inferiors (and know what packages those are
>> in) themselves.
>>
>> d) Have some better policies around when to use inputs and when
>> not to. This might be the most pragmatic approach, though it
>> means inconsistency from package to package.
>>
>> e) Build a suggested package mechanism into Guix. This has been
>> floated a couple times before. If it defaults to not installing
>> suggested packages, but telling the user about them, this would
>> be like option C, but making it easier to find which packages you
>> might need; if it installs them by default, it would work like
>> the current setup, but give users some kind of out to avoid the
>> extra bandwidth/disk usage. I don’t know how this would work for
>> declarative package setups -- how would I express to Guix Home
>> that it should install emacs-emms with flac (for metaflac), but
>> without mpg321, vorbis-tools, and mp3info?
> f) Implement parametrized packages 😉
Hello!
Do you know where can we find the parameterized packages code? The
original blog that documented the developments has been down for a long
time now.
[1] https://blog.lispy.tech
The author, Sarthak, said that an issue will be opened to track the
developments, but I'm not aware if it has already been created.
Best regards,
Sergio.
Re: emacs-git-email: Guix policy for dealing with abandoned packages with active forks
Kierin Bell writes: > Am I missing something, or would the code below do the same thing as > 'emacs-git-email'? Based only on the docstring (haven't reviewed the code), _some_ of the things emacs-git-email does are accounted for. However, it's not clear how some situations are handled: 1. Do patch series pose a complication or they're handled naturally? I'm unfamiliar with 'vc-prepare-patch', so this may be an obvious question. 2. Is there a way to associate a branch with an issue-specific email address? This can be useful for future revisions. 3. Some of the git-format-patch defaults are set in a manner assuming its use with git-send-mail. As such, these defaults are unsuitable when the patches are sent without git-send-mail. Are such issues corrected for? I'm aware of one such option, but unsure if there are others. Specifically, the --thread option in git-format-patch. This is not an issue in the guix repo due to ./etc/git/gitconfig , but is something that comes up generally. There are some other minor conveniences that emacs-git-email adds, but they have more to do with its integration with magit and thus may not be suitable for addition to core. E.g., ability to review and set the sendemail.to setting for the repository. > Could we submit a patch upstream to Emacs to make sending patches to > projects like Guix easier? Regardless of above, and without speaking for the Emacs maintainers, I think such patches to core would be a useful addition from a user's perspective. -- Suhail
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Hi Sergio!If you have since we last spoke made a public repository, I would loveto check it out.Thanks for your interest. Indeed, I created a repository meanwhile: < https://git.pub.solar/stefan/embedded-channel >.Hm, I should push my local changes – that repository is already pretty old, but I wouldn’t say outdated.The multilib issues I mentioned before are already solved there and it’s using GCC 14.2 with picolibc. ZMK is still at 2024-04-28.There is still no channel.scm, I still use guix build with the -L option, sorry.Locally I have a recent ZMK already with the new mouse emulation and I think GCC 15 with a newer picolibc. Stay tuned …ByeStefan
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Stefan writes: > Hi Sergio! > >> I'm very interested in the code for ZMK provided in this thread[1]. >> I've tried it locally and it compiles successfully. > > That's nice to hear! > >> Does anyone know if this is available in a public repository? Or if it has >> been moved forward? > > There is no public repository for it. I moved it a bit further. There is now a > GCC with picolibc. GCC in general is more self-contained and is completely > usable by itself (including paths to specs; Attila, this may solve the issue > you > were facing). There is no real need for GCC-toolchain packages anymore. > However, > as some projects invoke programs of Binutils directly and because of locales, > there are still GCC-toolchain packages. The Binutils for arm-none-eabi get > build > separately as well now, as the one from Guix has failing tests (if activated) > due to the selected configure flags. GCC is bumped to 13.2.0. Zephyr is > updated > to 3.5 and ZMK to end of April. There is also more ZMK support for combos, > conditional-layers and a bit more. > > A problem I figured for arm-none-eabi-g++ is that it always links the generic > libstdc++.a, instead of the existing CPU and FPU specific multilib variant > from a sub-directory. I'd appreciate any GCC configuration hint to solve this. Hello Stefan. Its been some time since you sent this message. I'm trying to test the example you attached and I cannot get it to build the custom GCC@13. Please, could you provide the `channels.scm` you use to compile it? I have the original code that you submitted in this repository[1], this one is no longer compiling from Guix at commit `1436165c2f0adbb44d3f033c54db692167591248`. Sadly, when I initially tested it, I forgot to save the `channels.scm` that made it compile. I will update the repository to your latest changes and add the `channels.scm` when I get it to compile. If you have since we last spoke made a public repository, I would love to check it out. [1] https://codeberg.org/pastor/guix-zmk If anyone has interest in having a community managed ZMK channel for Guix, please do not hesitate to join the conversation. Best regards, Sergio.
Re: guix shell --container from Shepherd to run a service
> I have a not yet running attempt of home assistant packaged, maybe you > would like to have a stab at it? thanks for the heads up, but i'm no expert of the python ecosystem. that's why i decided to first try it this way, instead of attempting to package it. also, HA is updated rather regularly. i don't want to lag behind too much, and guix package updates are more headache than a `pip install --upgrade` in the container (including reconfiguring into my own fork of guix while the patches are waiting in the queue). -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The way you treat yourself is ultimately how you will treat those you love most.” — Paul Conti
Re: guix shell --container from Shepherd to run a service
Hello Attila, > > (simple-service > 'home-assistant > shepherd-root-service-type > (list > (shepherd-service >(requirement '(file-systems networking guix-daemon)) >(provision '(home-assistant)) >(documentation "") >;; TODO herd stop doesn't work. it leaves the process >;; running without any errors. >(start > #~(lambda _ > (fork+exec-command > (list #$(file-append guix "/bin/guix") >"shell" >"--manifest=/srv/hass/manifest.scm" >"--container" >"--emulate-fhs" >"--network" >"--share=/srv/hass" >"--no-cwd" >"--expose=/gnu" >"--expose=/run/current-system" >"--" >#$(file-append bash "/bin/bash") >"-c" "cd /srv/hass && source bin/activate && > LD_LIBRARY_PATH=/lib:/lib64 hass --config=/srv/hass/config") > #:log-file "/var/log/home-assistant.log" > #:user '#$(user-account-name *hass-user*) > #:group '#$(user-account-group *hass-user*) > #:directory "/srv/hass" > #:supplementary-groups > '#$(user-account-supplementary-groups *hass-user*) > #:environment-variables > (list (string-append "HOME=/home/" > #$(user-account-name *hass-user*) > > notice that --expose=/gnu was needed, and possibly > --expose=/run/current-system, too, but i didn't double check every change. > > this way the `guix shell` call will get the versions from the hass user's > pull state; i.e. i can independently decide when to upgrade the guix > environment of the hass user and process. It's hard to judge well without the full source code, but the way you have it written seems more like that you're using the guix package declared in the channel rather than the user's guix. (if you weren't, I wouldn't expect file-append at all, but just something like "/home/*hass-user*/.config/guix/current/bin/guix"...) Meaning that user's pull state is irrelevant as the reference to guix is directly to the store. Also the reference would be to the pinned guix package in guix channel that you're probably not really using on your system. But all this is based on some assumptions of the code and how you use your system, so I totally might be wrong. Regards, Rutherther
Re: Emacs dependent package input question
Hi Sergio,
I've moved domain names, the final post is at
https://blog.coldboot.org/parameterized-packages-the-project-completion-update.html
You can find code for the project in this repository:
https://notabug.org/cel7t/guix-parameters
Additionally, the project completion report:
https://github.com/matchcase/parameterized-packages.org
I haven't been able to make an issue for this project because I'll need to
update bits of the code to ensure that it is working smoothly before
creating an issue and unfortunately I'm a bit occupied at the moment as I'm
writing my graduation thesis.
Best,
Sarthak.
On Sun, 6 Apr 2025, 19:16 Sergio Pastor Pérez,
wrote:
> Liliana Marie Prikler writes:
> > Am Samstag, dem 05.04.2025 um 09:38 -0700 schrieb Ian Eure:
> >> Hi Guixers,
> >>
> >> I’ve seen a few patches for Emacs packages lately which have the
> >> form:
> >>
> >> (package emacs-whatever
> >> (name "emacs-whatever")
> >> (description "Emacs interface for Whatever")
> >> (inputs (list whatever))
> >> (arguments
> >>(list
> >> #:phases
> >> (modify-phases %standard-phases
> >> (add-after 'unpack 'set-whatever-path
> >> (lambda (#:key inputs #:allow-other-keys)
> >> (emacs-substitute-variables "whatever.el"
> >> ("emacs-whatever-program"
> >> (search-inputs-file inputs
> >> "/bin/whatever")
> > Side note: the ordering of fields here looks rather displeasing.
> >
> >> ...and looking in emacs-xyz.scm, many packages do this. I
> >> understand why this pattern exists -- making the inferior an input
> >> means that installing the Emacs package Just Works -- but it also
> >> means increased disk consumption and somewhat less user
> >> flexibility.
> >>
> >> On the flexibility side, it means that if you install
> >> emacs-whatever and my-personal-whatever-fork, emacs-whatever will
> >> continue using the stock whatever, not your fork; making this work
> >> requires transforming emacs-whatever to replace the input. I
> >> think that because this behavior is so different from how most
> >> other operating systems work, it’s surprising, and the solution
> >> isn’t obvious.
> > You obviously can still customize it to use a PATH lookup. You are
> > wasting disk space if you do so. Alternatively, input rewriting such
> > as the --with-input command line flag replace whatever with your-
> > personal-whatever-fork and thus do exactly what you want.
> >
> >> […]
> >> I’m not sure how to do that, though. I can think of a few
> >> options:
> >>
> >> a) Leave it as is. Don’t love it, but if there’s concensus that
> >> this is the right way, then okay.
> >>
> >> b) Make packages that align better with specific usecases,
> >> ex. emacs-emacsql-sqlite, -mysql, etc. This feels fraught to me,
> >> and I don’t think it works if you get emacs-emacsql-sqlite as an
> >> input to some other emacs-* package, but want emacs-emacsql-mysql
> >> as a user. Perhaps metapackages which only exist to combine
> >> dependencies would make this a workable approach.
> >>
> >> c) Don’t set them at all, and use the same $PATH late binding as
> >> is typical of other Emacs setups. This would mean that
> >> installing Emacs packages wouldn’t Just Work, and users would
> >> have to install the inferiors (and know what packages those are
> >> in) themselves.
> >>
> >> d) Have some better policies around when to use inputs and when
> >> not to. This might be the most pragmatic approach, though it
> >> means inconsistency from package to package.
> >>
> >> e) Build a suggested package mechanism into Guix. This has been
> >> floated a couple times before. If it defaults to not installing
> >> suggested packages, but telling the user about them, this would
> >> be like option C, but making it easier to find which packages you
> >> might need; if it installs them by default, it would work like
> >> the current setup, but give users some kind of out to avoid the
> >> extra bandwidth/disk usage. I don’t know how this would work for
> >> declarative package setups -- how would I express to Guix Home
> >> that it should install emacs-emms with flac (for metaflac), but
> >> without mpg321, vorbis-tools, and mp3info?
> > f) Implement parametrized packages 😉
>
> Hello!
>
> Do you know where can we find the parameterized packages code? The
> original blog that documented the developments has been down for a long
> time now.
>
> [1] https://blog.lispy.tech
>
> The author, Sarthak, said that an issue will be opened to track the
> developments, but I'm not aware if it has already been created.
>
>
> Best regards,
> Sergio.
>
Re: guix shell --container from Shepherd to run a service
> It's hard to judge well without the full source code, but the way you > have it written seems more like that you're using the guix package > declared in the channel rather than the user's guix. (if you weren't, I > wouldn't expect file-append at all, but just something like > "/home/hass-user/.config/guix/current/bin/guix"...) Meaning that user's > pull state is irrelevant as the reference to guix is directly to the > store. Also the reference would be to the pinned guix package in guix > channel that you're probably not really using on your system. you're right. apparently i still don't understand profiles deep enough to avoid such thinkos. i've changed the way i refer to the guix binary to use the path you suggested. thank you Rutherther! -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Each individual best promotes his own self-interest by peaceful, social cooperation as in the free market. Indeed, the more I make of myself the more are others served by my existence […] The way to assume 'social responsibility' is for the individual to rise […] as far as possible.” — Leonard E. Read (1898–1983), 'Let Freedom Reign' (1969)
