* Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
@ 2022-12-18 1:54 Mekeor Melire
2022-12-18 8:11 ` Liliana Marie Prikler
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Mekeor Melire @ 2022-12-18 1:54 UTC (permalink / raw)
To: Guix Devel
[-- Attachment #1: Type: text/plain, Size: 3390 bytes --]
Hello,
I'd like to share some code, thus prove a concept, ask for
feedback, and ask if it could makes sense, under certain
circumstances, to provide similar code in GNU Guix. The code can
be used in a ~manifest.scm~ file (but probably could also be used
with ~guix package -e~ or inside ~guix repl~) where it can be used
to import all ~emacs-*~ packages that are loaded with
~(use-package PACKAGE [...])~ inside an Elisp-file like ~init.el~:
#+begin_src scheme
;; ~/some/manifest.scm
(specifications->manifest
(append
(el/file->specifications "/home/user/.emacs.d/init.el")
(list
"emacs"
"git"
"gnupg"
"mu"
"syncthing")))
#+end_src
It has many severe caveats, including but not limited to:
1. The code uses Guile/Scheme's ~read~ function which interprets
the Elisp-file as Scheme. Thus, the code does not really find out
which packages are loaded, but rather it only looks for the
~(use-package PACKAGE [...])~ pattern of an S-expression. E.g.
something like ~(apply 'use-package foo)~ won't be caught. (I
don't expect Guile's Emacs-Lisp language-feature to be mature
enough to be usable for this.)
2. Not all external packages are loaded with ~use-package~. E.g.
~(require 'foo)~ might be used directly. But it'd be possible to
extend the code to allow several ways/patterns of importing
packages, and maybe also to specify custom patterns.
3. Not all S-expressions that match against ~(use-package
PACKAGE)~ are load external packages. E.g. ~(if nil (use-package
foo))~ won't load anything at all. Also, neither ~(use-package
emacs)~ nor ~(use-package savehist)~ will load anything, because
they ~require~ features that ship with GNU Emacs by default.
That's why the functions in the appended code offer an optional
keyword argument, #:block, in order to block a list packages.
4. The ~manifest.scm~ is not the single source of truth anymore.
I.e. this code compromises the purpose of a manifest. (It's
possible to extend the code such that the Elisp-file's hash can
optionally be verified with given hash.)
Nevertheless, for me, personally, it's pretty neat and handy to
use, because I don't need to maintain the list of emacs-packages
in two places. I also think that it could come pretty handy for
many others, at least in order to initialize their user-profile,
by running something like ~guix package -e '(some-magic
"/home/user/.emacs.d/init.el")'~.
What do you think? Should this go into a separate, private
channel? Into the Guix Cookbook? Into Guix, if so, then probably
with lots of changes? Should it just stay here, in this mailing
list thread? Or do you think this is just a bad idea in general?
I should mention that I go the idea for this code from the
Nix-Community's Emacs-Overlay which offers a similar feature; as
described in their README as follows:
#+begin_src nix
#
https://github.com/nix-community/emacs-overlay#extra-library-functionality
{
environment.systemPackages = [
(emacsWithPackagesFromUsePackage {
# Your Emacs config file. Org mode babel files are also
# supported.
# NB: Config files cannot contain unicode characters, since
# they're being parsed in nix, which lacks unicode
# support.
# config = ./emacs.org;
config = ./emacs.el;
# ...
})]}
#+end_src
Here's the code. Please show mercy, it's my first real Scheme
code:
[-- Attachment #2: el-manifest.scm --]
[-- Type: text/plain, Size: 4133 bytes --]
(define-module (manifest)
#:autoload (gnu packages) (specifications->manifest)
#:autoload (srfi srfi-1) (drop fold-right)
#:autoload (ice-9 textual-ports) (get-string-all))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; LIBRARY
(define el/default-block
;; "Default list of packages, as symbols, which will be blocked. It's a subset
;; default features provided by GNU Emacs."
'(emacs hl-line outline savehist))
(define* (el/file->specifications content-f #:key (block el/default-block))
"Given the file-path CONTENT-F, interprete it as an Emacs-Lisp source-code
and extract a list of package-names, as strings, that have been loaded using
(use-package PACKAGE [...])."
(call-with-input-file content-f
(lambda (input) (el/port->specifications input #:block block))))
(define* (el/string->specifications content-s #:key (block el/default-block))
"Given a string CONTENT-S, interprete it as an Emacs-Lispsource-code and
extract a list of package-names, as strings, that have been loaded using
(use-package PACKAGE [...])."
(call-with-input-string content-s
(lambda (input) (el/port->specifications input #:block block))))
(define* (el/port->specifications content-p #:key (block el/default-block))
"Given the input-port CONTENT-P, interprete it as an Emacs-Lisp source-code
and extract a list of package-names, as strings, that have been loaded using
(use-package PACKAGE [...])."
(let*
((content-string-or-eof
(get-string-all content-p))
(content-string
(if
(eof-object? content-string-or-eof)
""
content-string-or-eof))
;; let's wrap the file into a (quote ...) so that a single invocation of ~read~ will read the whole file
(quoted-content-string
(string-append "(quote " content-string "\n)"))
(content-expression
(with-input-from-string quoted-content-string read)))
(map
(lambda (package-string) (string-append "emacs-" package-string))
(map
symbol->string
(filter
(lambda (package-expression) (not (member package-expression block)))
(el/find-used-packages content-expression (list)))))))
(define (el/find-used-packages expression accumulator)
"Given a quoted expression EXPRESSION and an accumulator ACCUMULATOR,
being a list of package names, add all package-names into ACCUMULATOR, that
have been loaded with (use-package PACKAGE [...]), and return that possibly
expanded list."
(cond
;; in case of no s-expression, return accumulator
((not (list? (peek expression))) accumulator)
;; in case of an empty s-expression, (), return accumulator
((nil? expression) accumulator)
;; in case of an s-expression with a single element, (X), walk into that element
((nil? (cdr expression))
(el/find-used-packages (car expression) accumulator))
;; in case of an use-package s-expression, (use-package PACKAGE [...]), add PACKAGE to the accumulator and also add those elements which possibly result from walking through the remaining elements
((and
(eq? (car expression) 'use-package)
(symbol? (cadr expression)))
(fold-right
el/find-used-packages
(let
((package (cadr expression)))
(if
(member package accumulator)
accumulator
(cons package accumulator)))
(drop expression 2)))
;; in case of a s-expression with at least two elements, (X Y [...]), walk through all of them
(#t
(fold-right
el/find-used-packages
accumulator
expression))))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; MANIFEST
(specifications->manifest
(append
(el/file->specifications "/home/user/.emacs.d/configuration.el" #:block
;; block some packages as they won't be loaded on this host:
(cons*
'gist
'guix-emacs
'hide-lines
'json
'kubernetes
'vertico-directory
el/default-block))
(list
"emacs"
"git"
"isync"
"mu")))
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
2022-12-18 1:54 Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm Mekeor Melire
@ 2022-12-18 8:11 ` Liliana Marie Prikler
2022-12-19 10:15 ` Andrew Tropin
2022-12-20 9:16 ` Mekeor Melire
2022-12-19 10:42 ` zimoun
2022-12-28 0:51 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
2 siblings, 2 replies; 13+ messages in thread
From: Liliana Marie Prikler @ 2022-12-18 8:11 UTC (permalink / raw)
To: Mekeor Melire, Guix Devel; +Cc: Andrew Tropin
Am Sonntag, dem 18.12.2022 um 01:54 +0000 schrieb Mekeor Melire:
> Nevertheless, for me, personally, it's pretty neat and handy to
> use, because I don't need to maintain the list of emacs-packages
> in two places. I also think that it could come pretty handy for
> many others, at least in order to initialize their user-profile,
> by running something like ~guix package -e '(some-magic
> "/home/user/.emacs.d/init.el")'~.
I think we should be able to build an Emacs service in Guix Home that
can manage init.el. As a workaround, use-package should also have a
:when clause, so you can use :when (featurep 'some-package-autoloads)
if you're unsure whether 'some-package is actually installed. This
makes your init file a little more resilient and is particularly useful
with pure shells.
> What do you think? Should this go into a separate, private
> channel? Into the Guix Cookbook? Into Guix, if so, then probably
> with lots of changes? Should it just stay here, in this mailing
> list thread? Or do you think this is just a bad idea in general?
Given the caveats, I would rather like to see an Emacs Lisp based
script that mocks use-package and generates a manifest by evaluting
init.el. This should give you more correct results. It's not a bad
idea per se, but as-is, I think it would better be maintained in your
own channel before upstreaming.
For upstreaming, I see two potential paths. The first one would be
integration to `guix home import', which Andrew Tropin (CC'd) could
probably tell you more on. The second would be integration into `guix
package' as a callable function/command line argument, but IMHO that's
less likely to pass.
Cheers
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
2022-12-18 8:11 ` Liliana Marie Prikler
@ 2022-12-19 10:15 ` Andrew Tropin
2022-12-20 9:45 ` Mekeor Melire
2022-12-20 9:16 ` Mekeor Melire
1 sibling, 1 reply; 13+ messages in thread
From: Andrew Tropin @ 2022-12-19 10:15 UTC (permalink / raw)
To: Liliana Marie Prikler, Mekeor Melire, Guix Devel
[-- Attachment #1: Type: text/plain, Size: 3281 bytes --]
On 2022-12-18 09:11, Liliana Marie Prikler wrote:
> Am Sonntag, dem 18.12.2022 um 01:54 +0000 schrieb Mekeor Melire:
>> Nevertheless, for me, personally, it's pretty neat and handy to
>> use, because I don't need to maintain the list of emacs-packages
>> in two places. I also think that it could come pretty handy for
>> many others, at least in order to initialize their user-profile,
>> by running something like ~guix package -e '(some-magic
>> "/home/user/.emacs.d/init.el")'~.
> I think we should be able to build an Emacs service in Guix Home that
> can manage init.el. As a workaround, use-package should also have a
> :when clause, so you can use :when (featurep 'some-package-autoloads)
> if you're unsure whether 'some-package is actually installed. This
> makes your init file a little more resilient and is particularly useful
> with pure shells.
>
>> What do you think? Should this go into a separate, private
>> channel? Into the Guix Cookbook? Into Guix, if so, then probably
>> with lots of changes? Should it just stay here, in this mailing
>> list thread? Or do you think this is just a bad idea in general?
> Given the caveats, I would rather like to see an Emacs Lisp based
> script that mocks use-package and generates a manifest by evaluting
> init.el. This should give you more correct results. It's not a bad
> idea per se, but as-is, I think it would better be maintained in your
> own channel before upstreaming.
>
> For upstreaming, I see two potential paths. The first one would be
> integration to `guix home import', which Andrew Tropin (CC'd) could
> probably tell you more on.
I'm neither the author, nor the user of guix home import, however I
think it could be a good place for such a functionality, but I would
suggest to maintain this helper functions for a while in a personal
channel, mature it and revisit this question later.
To make a solution more robust and complete, you can take a look at
straight.el and how it redefines use-package-ensure-function and do
something similiar to generate a list of packages for guix. Another
detail is that use-package accepts a symbol value for :ensure and you
can write something like:
--8<---------------cut here---------------start------------->8---
;; (setq use-package-always-ensure t) ; as an alternative to :ensure t
(use-package vertico
:ensure t
...)
(use-package vertico-directory
:ensure vertico
...)
--8<---------------cut here---------------end--------------->8---
This way you won't need a concept of "blocked" packages.
One more idea: make a function which accepts file-like/origin object
instead of string and generates a package with propagated-dependencies
based on the content of source code provided as an argument.
Personally, with my emacs config I do the things vice versa: I have
elisp code in scheme files with a list of explicit dependencies:
https://git.sr.ht/~abcdw/rde/tree/b57387f2/src/rde/features/emacs-xyz.scm#L946
Nevertheless, your idea with use-package looks good to me.
> The second would be integration into `guix package' as a callable
> function/command line argument, but IMHO that's less likely to pass.
>
>
> Cheers
--
Best regards,
Andrew Tropin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
2022-12-18 1:54 Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm Mekeor Melire
2022-12-18 8:11 ` Liliana Marie Prikler
@ 2022-12-19 10:42 ` zimoun
2022-12-28 0:51 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
2 siblings, 0 replies; 13+ messages in thread
From: zimoun @ 2022-12-19 10:42 UTC (permalink / raw)
To: Mekeor Melire, Guix Devel
Hi,
On Sun, 18 Dec 2022 at 01:54, Mekeor Melire <mekeor@posteo.de> wrote:
> What do you think? Should this go into a separate, private
> channel? Into the Guix Cookbook? Into Guix, if so, then probably
> with lots of changes? Should it just stay here, in this mailing
> list thread? Or do you think this is just a bad idea in general?
From my point of view, you could convert to an extension, say “guix
emacs” and share this extension as a regular Guix packages. This would
help to iterate and discuss various implementation details using
concrete and easy tests.
Cheers,
simon
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
2022-12-18 8:11 ` Liliana Marie Prikler
2022-12-19 10:15 ` Andrew Tropin
@ 2022-12-20 9:16 ` Mekeor Melire
2022-12-20 15:06 ` Andrew Tropin
1 sibling, 1 reply; 13+ messages in thread
From: Mekeor Melire @ 2022-12-20 9:16 UTC (permalink / raw)
To: Liliana Marie Prikler; +Cc: Andrew Tropin, guix-devel
2022-12-18 09:11 liliana.prikler@gmail.com:
> I think we should be able to build an Emacs service in Guix Home that can
> manage init.el. As a workaround, use-package should also have a :when
> clause, so you can use :when (featurep 'some-package-autoloads) if you're
> unsure whether 'some-package is actually installed. This makes your init
> file a little more resilient and is particularly useful with pure shells.
=guix home import= for init.el is a great idea! (See below for use-cases.)
And yes, =:when (featurep 'some-package-autoloads)= is a workaround that makes
init.el files loadable even if respective packages are not available. But the
submitted code aims to enable you to install needed emacs-packages so that
such a restricting workaround is not needed.
> Given the caveats, I would rather like to see an Emacs Lisp based script
> that mocks use-package and generates a manifest by evaluting init.el. This
> should give you more correct results. It's not a bad idea per se, but as-is,
> I think it would better be maintained in your own channel before
> upstreaming.
Problem is that in cases where needed packages are not installed and the user
did not add =:when (featurep 'foo)= everywhere, it's possible that evaluating
init.el will fail because of some package not being available. Thus, IMHO, we
can't rely on Emacs to evaluate the init.el. But we could use Emacs to expand
the (use-package) macros inside init.el. But I doubt that it's worth it. I
rather think it's easier to use Guile to parse invocations of =require= and
=use-package=.
> For upstreaming, I see two potential paths. The first one would be
> integration to `guix home import', which Andrew Tropin (CC'd) could probably
> tell you more on. The second would be integration into `guix package' as a
> callable function/command line argument, but IMHO that's less likely to
> pass.
All in all, I think there are three use-cases:
- If you want Guix Home to handle the installation of emacs- packages, there
should be =guix home import= to automatically install those packages, as
resulting from early- and init.el files.
- If you simply want to install all emacs- packages once per CLI, there should
be =guix package --install-from-elisp-file=~/.emacs.d/init.el= and similar
CLI-arguments or -commands, such as --install-from-elisp-expression,
--install-from-elisp-init-files. There could also be --fit-to-elisp-
variants which not only install packages, but also remove redundant, unused
emacs-* packages.
- If you want to use a manifest.scm for your Guix user-profile and import
appropriate emacs- therein, there should be Guile modules and functions
which allow to do so, as the submitted code does. Those modules could also
be used with =guix package -e=.
And in all three cases, your early- and init.el files might load packages via
=require= or =use-package= at least.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
2022-12-19 10:15 ` Andrew Tropin
@ 2022-12-20 9:45 ` Mekeor Melire
2022-12-20 14:56 ` Andrew Tropin
0 siblings, 1 reply; 13+ messages in thread
From: Mekeor Melire @ 2022-12-20 9:45 UTC (permalink / raw)
To: Andrew Tropin; +Cc: Liliana Marie Prikler, guix-devel
2022-12-19 14:15 andrew@trop.in:
> On 2022-12-18 09:11, Liliana Marie Prikler wrote:
>
> > Am Sonntag, dem 18.12.2022 um 01:54 +0000 schrieb Mekeor Melire:
> I'm neither the author, nor the user of guix home import, however I think it
> could be a good place for such a functionality, but I would suggest to
> maintain this helper functions for a while in a personal channel, mature it
> and revisit this question later.
Good idea. But separating this into a personal channel could also lead to the
feature being forgotten.
> To make a solution more robust and complete, you can take a look at
> straight.el and how it redefines use-package-ensure-function and do
> something similiar to generate a list of packages for guix. Another detail
> is that use-package accepts a symbol value for :ensure and you can write
> something like:
>
> ;; (setq use-package-always-ensure t) ; as an alternative to :ensure t
> (use-package vertico
> :ensure t
> ...)
>
> (use-package vertico-directory
> :ensure vertico
> ...)
True! The parser should consider the :ensure keyword.
> This way you won't need a concept of "blocked" packages.
It'd still be good to have such a concept in order to block packages that
won't be used on Guix-driven system. For example:
#+begin_src elisp
(when (this-is-not-a-guix-driven-system)
(use-package some-package-that-is-not-packaged-for-guix))
;; or equivalently
(use-package some-package-that-is-not-packaged-for-guix
:when (this-is-not-a-guix-driven-system))
#+end_src
> One more idea: make a function which accepts file-like/origin object instead
> of string and generates a package with propagated-dependencies based on the
> content of source code provided as an argument.
You mean something like this?:
#+begin_src scheme
(define-public my-emacs
(emacs-from-init
:custom-emacs-package emacs-with-athena-instead-of-gtk
:init "/home/user/.emacs.d/init.el"))
#+end_src
By the way, this won't be a "pure" package. When using
=emacsWithPackagesFromUsePackage= feature from nix-community's emacs-overlay,
I needed to pass an --impure flag.
> Personally, with my emacs config I do the things vice versa: I have elisp
> code in scheme files with a list of explicit dependencies:
>
> https://git.sr.ht/~abcdw/rde/tree/b57387f2/src/rde/features/emacs-xyz.scm#L946
Interesting!
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
2022-12-20 9:45 ` Mekeor Melire
@ 2022-12-20 14:56 ` Andrew Tropin
0 siblings, 0 replies; 13+ messages in thread
From: Andrew Tropin @ 2022-12-20 14:56 UTC (permalink / raw)
To: Mekeor Melire; +Cc: Liliana Marie Prikler, guix-devel
[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]
On 2022-12-20 09:45, Mekeor Melire wrote:
> 2022-12-19 14:15 andrew@trop.in:
>
>> On 2022-12-18 09:11, Liliana Marie Prikler wrote:
>>
>> > Am Sonntag, dem 18.12.2022 um 01:54 +0000 schrieb Mekeor Melire:
>
>> I'm neither the author, nor the user of guix home import, however I think it
>> could be a good place for such a functionality, but I would suggest to
>> maintain this helper functions for a while in a personal channel, mature it
>> and revisit this question later.
>
> Good idea. But separating this into a personal channel could also lead to the
> feature being forgotten.
>
>> To make a solution more robust and complete, you can take a look at
>> straight.el and how it redefines use-package-ensure-function and do
>> something similiar to generate a list of packages for guix. Another detail
>> is that use-package accepts a symbol value for :ensure and you can write
>> something like:
>>
>> ;; (setq use-package-always-ensure t) ; as an alternative to :ensure t
>> (use-package vertico
>> :ensure t
>> ...)
>>
>> (use-package vertico-directory
>> :ensure vertico
>> ...)
>
> True! The parser should consider the :ensure keyword.
>
>> This way you won't need a concept of "blocked" packages.
>
> It'd still be good to have such a concept in order to block packages that
> won't be used on Guix-driven system. For example:
>
> #+begin_src elisp
> (when (this-is-not-a-guix-driven-system)
> (use-package some-package-that-is-not-packaged-for-guix))
>
> ;; or equivalently
>
> (use-package some-package-that-is-not-packaged-for-guix
> :when (this-is-not-a-guix-driven-system))
> #+end_src
>
>> One more idea: make a function which accepts file-like/origin object instead
>> of string and generates a package with propagated-dependencies based on the
>> content of source code provided as an argument.
>
> You mean something like this?:
>
> #+begin_src scheme
> (define-public my-emacs
> (emacs-from-init
> :custom-emacs-package emacs-with-athena-instead-of-gtk
> :init "/home/user/.emacs.d/init.el"))
> #+end_src
I meant something like this:
--8<---------------cut here---------------start------------->8---
(package-propagating-guix-packages-extracted-from-elisp-configuration
;; or just (local-file "./emacs/init.el") or maybe even a remote
;; repository with emacs configuration.
#:configuration (local-file "./emacs/configuration/directory"
#:recursive? #t))
--8<---------------cut here---------------end--------------->8---
>
> By the way, this won't be a "pure" package. When using
> =emacsWithPackagesFromUsePackage= feature from nix-community's emacs-overlay,
> I needed to pass an --impure flag.
>
>> Personally, with my emacs config I do the things vice versa: I have elisp
>> code in scheme files with a list of explicit dependencies:
>>
>> https://git.sr.ht/~abcdw/rde/tree/b57387f2/src/rde/features/emacs-xyz.scm#L946
>
> Interesting!
--
Best regards,
Andrew Tropin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
2022-12-20 9:16 ` Mekeor Melire
@ 2022-12-20 15:06 ` Andrew Tropin
0 siblings, 0 replies; 13+ messages in thread
From: Andrew Tropin @ 2022-12-20 15:06 UTC (permalink / raw)
To: Mekeor Melire, Liliana Marie Prikler; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 3797 bytes --]
On 2022-12-20 09:16, Mekeor Melire wrote:
> 2022-12-18 09:11 liliana.prikler@gmail.com:
>
>> I think we should be able to build an Emacs service in Guix Home that can
>> manage init.el. As a workaround, use-package should also have a :when
>> clause, so you can use :when (featurep 'some-package-autoloads) if you're
>> unsure whether 'some-package is actually installed. This makes your init
>> file a little more resilient and is particularly useful with pure shells.
>
> =guix home import= for init.el is a great idea! (See below for use-cases.)
>
> And yes, =:when (featurep 'some-package-autoloads)= is a workaround that makes
> init.el files loadable even if respective packages are not available. But the
> submitted code aims to enable you to install needed emacs-packages so that
> such a restricting workaround is not needed.
>
>> Given the caveats, I would rather like to see an Emacs Lisp based script
>> that mocks use-package and generates a manifest by evaluting init.el. This
>> should give you more correct results. It's not a bad idea per se, but as-is,
>> I think it would better be maintained in your own channel before
>> upstreaming.
>
> Problem is that in cases where needed packages are not installed and the user
> did not add =:when (featurep 'foo)= everywhere, it's possible that evaluating
> init.el will fail because of some package not being available. Thus, IMHO, we
> can't rely on Emacs to evaluate the init.el. But we could use Emacs to expand
> the (use-package) macros inside init.el. But I doubt that it's worth it. I
> rather think it's easier to use Guile to parse invocations of =require= and
> =use-package=.
>
>> For upstreaming, I see two potential paths. The first one would be
>> integration to `guix home import', which Andrew Tropin (CC'd) could probably
>> tell you more on. The second would be integration into `guix package' as a
>> callable function/command line argument, but IMHO that's less likely to
>> pass.
>
> All in all, I think there are three use-cases:
>
> - If you want Guix Home to handle the installation of emacs- packages, there
> should be =guix home import= to automatically install those packages, as
> resulting from early- and init.el files.
guix home import doesn't install anything, it only generates a configuration.
>
> - If you simply want to install all emacs- packages once per CLI, there should
> be =guix package --install-from-elisp-file=~/.emacs.d/init.el= and similar
> CLI-arguments or -commands, such as --install-from-elisp-expression,
> --install-from-elisp-init-files. There could also be --fit-to-elisp-
> variants which not only install packages, but also remove redundant, unused
> emacs-* packages.
I don't think we want a separate tricky flags here. Especially we don't
want some implicit logic removing unused packages. Just
--8<---------------cut here---------------start------------->8---
guix package --install-from-expression=\
((@ (mekeor emacs-helper) generate-package-from-elisp) \
#:elisp (local-file "./init.el"))
--8<---------------cut here---------------end--------------->8---
should be enough. If you want to be sure unused packages are not
installed just don't use imperative guix package and maintain you
configuration in declarative manner.
>
> - If you want to use a manifest.scm for your Guix user-profile and
> import appropriate emacs- therein, there should be Guile modules and
> functions which allow to do so, as the submitted code does. Those
> modules could also be used with =guix package -e=.
>
> And in all three cases, your early- and init.el files might load packages via
> =require= or =use-package= at least.
--
Best regards,
Andrew Tropin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
[not found] <875ydxi4xn.fsf@posteo.de>
@ 2022-12-27 18:52 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
0 siblings, 0 replies; 13+ messages in thread
From: Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution. @ 2022-12-27 18:52 UTC (permalink / raw)
To: Mekeor Melire, guix-devel
Right you are, I am quite new to mailing lists and I thought emacs would “do the right thing”.
- Mitchell
> On Dec 27, 2022, at 4:15 AM, Mekeor Melire <mekeor@posteo.de> wrote:
>
> 2022-12-26 14:20 mitchellschmeisser@librem.one:
>
>> Perhaps you are thinking about this upside down?
>>
>> emacs has support for guix via `emacs-guix`.
>> Would it not make more sense to make a drop in replacement for
>> `use-package` which is syntactically identical but instead of
>> downloading stuff from the emacs package eco-system it installs it from
>> guix into a special emacs managed profile.
>>
>> Then to use it you would just install the `guix-emacs-use-package`
>> instead of `emacs-use-package`.
>>
>> - Mitchell
>
> That's an interesting idea, thanks for sharing. I think it'd be nice if you shared it not only with me but with the whole mailing-list (guix-devel).
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
2022-12-18 1:54 Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm Mekeor Melire
2022-12-18 8:11 ` Liliana Marie Prikler
2022-12-19 10:42 ` zimoun
@ 2022-12-28 0:51 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
2023-02-02 9:44 ` Mekeor Melire
2 siblings, 1 reply; 13+ messages in thread
From: Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution. @ 2022-12-28 0:51 UTC (permalink / raw)
To: Mekeor Melire, guix-devel
Mekeor Melire <mekeor@posteo.de> writes:
>> Perhaps you are thinking about this upside down?
>>
>> emacs has support for guix via `emacs-guix`.
>> Would it not make more sense to make a drop in replacement for
>> `use-package` which is syntactically identical but instead of
>> downloading stuff from the emacs package eco-system it installs it from
>> guix into a special emacs managed profile.
>>
>> Then to use it you would just install the `guix-emacs-use-package`
>> instead of `emacs-use-package`.
>>
>> - Mitchell
>
> That's an interesting idea, thanks for sharing. I think it'd be nice if you shared it not only with me but with the whole mailing-list (guix-devel).
Here is a naive implementation which extends use-package to use guix to
ensure packages.
It turns out `use-package` allows you to customize the ensure function.
This is mostly a plagiarized version of the use-package-ensure-elpa.
It creates a profile in ~/.emacs.d./guix-profile by default and every
package which is marked `:ensure t` will be prompted for install.
Set `use-package-ensure-function` to #'use-package-ensure-guix.
#+BEGIN_SRC emacs-lisp
(require 'use-package)
(require 'use-package-guix)
(setq use-package-ensure-function #'use-package-ensure-guix)
#+END_SRC
This is kind of nice because we can now use the `emacs-guix` interfaces
for managing our `use-package` specifications i.e. updates/removal
It is a bit annoying at first because it prompts for y/n verification
for every package but I think this behavior is desirable.
This is my first emacs package so I'm sure there are many things which
can be improved.
#+BEGIN_SRC emacs-lisp
(require 'guix)
(require 'guix-profiles)
(require 'guix-read)
(require 'guix-ui-package)
(defgroup use-package-guix nil
"use-package support for guix"
:group 'use-package-ensure)
(defcustom use-package-profile (concat (getenv "HOME") "/.emacs.d/guix-profile")
"Location of use-package guix profile"
:type 'string
:group 'use-package-guix)
(defun guix-package-installed-p (package)
(bui-assoc-value package 'installed))
(defun canonicalize-name (package-name)
"Make sure package name has \"emacs-\" prefix"
(if (string-match "^emacs-.+" package-name)
package-name
(concat "emacs-" package-name)))
(defun emacs-package->guix-package (package)
"Return guix package from package name"
(car (guix-output-list-get-entries use-package-profile 'name
(canonicalize-name package))))
(defun guix-package-id (package)
(bui-entry-non-void-value package 'id))
(defun guix-install-package (package)
(if (guix-package-installed-p package)
t
(guix-process-package-actions
use-package-profile
`((install (,(string-to-number (car (split-string (bui-entry-id package) ":"))) "out"))))
(current-buffer)))
(defun guix-installed-packages ()
(guix-output-list-get-entries use-package-profile 'installed))
(defun use-package-ensure-guix (name args _state &optional _no-refresh)
(dolist (ensure args)
(let ((package
(or (and (eq ensure t)
(use-package-as-symbol name))
ensure)))
(when package
(when (consp package)
(use-package-pin-package (car package) (cdr package))
(setq package (car package)))
(let ((package (emacs-package->guix-package (use-package-as-string package))))
(unless (guix-package-installed-p package)
(condition-case-unless-debug err
(progn
(when (assoc package (bound-and-true-p
package-pinned-packages))
(package-read-all-archive-contents))
(if (assoc package package-archive-contents)
(package-install package)
(package-refresh-contents)
(when (assoc package (bound-and-true-p
package-pinned-packages))
(package-read-all-archive-contents))
(guix-install-package package))
t)
(error
(display-warning 'use-package
(format "Failed to install %s: %s"
name (error-message-string err))
:error)))))))))
;;;###autoload
(add-to-list 'load-path (concat use-package-profile "/share/emacs/site-lisp"))
(provide 'use-package-guix)
#+END_SRC
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
2022-12-28 0:51 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
@ 2023-02-02 9:44 ` Mekeor Melire
2023-02-03 2:20 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
2023-02-03 2:31 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
0 siblings, 2 replies; 13+ messages in thread
From: Mekeor Melire @ 2023-02-02 9:44 UTC (permalink / raw)
To: Mitchell Schmeisser; +Cc: guix-devel
2022-12-27 19:51 mitchellschmeisser@librem.one:
> Mekeor Melire <mekeor@posteo.de> writes:
>
> Here is a naive implementation which extends use-package to use
> guix to ensure packages.
Thank you very much for this great snippet of code. I just
successfully set it up locally and I'm very happy.
Would you like to create a public Git repository for this
elisp-package so that we can collaborate on it? If you don't have
time to do it, I can create a public Git repository (with your
copyright note; under GPLv3+?; formally owned by an
"organization").
Personally, I'm also very much of a noob in things elisp. But
intuitively, I'd suggest these changes:
> It is a bit annoying at first because it prompts for y/n
> verification for every package but I think this behavior is
> desirable.
Personally, I found that behaviour a little tidyous. I'd suggest
to make it at least configurable.
> #+BEGIN_SRC emacs-lisp
> (require 'guix)
> (require 'guix-profiles)
> (require 'guix-read)
> (require 'guix-ui-package)
>
>
> (defgroup use-package-guix nil
What do you think about naming this package/feature
"use-package-ensure-guix" and using that as a prefix for all other
functions and variables -- except for use-package-ensure-guix? I
think "use-package-ensure-guix" would be a good package name
because it's pretty much the only (important) function which this
packages aims to offer. So, …
> "use-package support for guix" :group 'use-package-ensure)
>
> (defcustom use-package-profile (concat (getenv "HOME")
> "/.emacs.d/guix-profile")
… this variable would then perhaps be renamed into
"use-package-ensure-guix-profile" or so.
> "Location of use-package guix profile" :type 'string :group
> 'use-package-guix)
>
> (defun guix-package-installed-p (package)
> (bui-assoc-value package 'installed))
>
> (defun canonicalize-name (package-name)
> "Make sure package name has \"emacs-\" prefix"
> (if (string-match "^emacs-.+" package-name)
> package-name
> (concat "emacs-" package-name)))
>
> (defun emacs-package->guix-package (package)
> "Return guix package from package name"
> (car (guix-output-list-get-entries use-package-profile 'name
> (canonicalize-name
> package))))
>
> (defun guix-package-id (package)
> (bui-entry-non-void-value package 'id))
(This function could be removed, I think.)
> (defun guix-install-package (package)
> (if (guix-package-installed-p package)
> t
> (guix-process-package-actions
> use-package-profile
> `((install (,(string-to-number (car (split-string
> (bui-entry-id package) ":"))) "out"))))
> (current-buffer)))
>
> (defun guix-installed-packages ()
> (guix-output-list-get-entries use-package-profile 'installed))
>
>
> (defun use-package-ensure-guix (name args _state &optional
> _no-refresh)
> (dolist (ensure args)
> (let ((package
> (or (and (eq ensure t)
> (use-package-as-symbol name))
> ensure)))
> (when package
> (when (consp package)
> (use-package-pin-package (car package) (cdr package))
> (setq package (car package)))
>
> (let ((package (emacs-package->guix-package
> (use-package-as-string package))))
> (unless (guix-package-installed-p package)
> (condition-case-unless-debug err
> (progn
> (when (assoc package (bound-and-true-p
> package-pinned-packages))
> (package-read-all-archive-contents))
> (if (assoc package package-archive-contents)
> (package-install package)
> (package-refresh-contents)
> (when (assoc package (bound-and-true-p
> package-pinned-packages))
> (package-read-all-archive-contents))
> (guix-install-package package))
> t)
What is the purpose of this long (progn …)? Could we instead
simply write (guix-install-package package)?
>
> (error (display-warning 'use-package (format
> "Failed to
> install %s: %s" name (error-message-string err))
> :error)))))))))
I'd suggest to miss the "error" label on this message, and rather
label it as "warning" (which is the default). We could also
suggest to add ":ensure nil" if it's a built-in feature. (E.g. in
case of (use-package recentf).)
> ;;;###autoload
> (add-to-list 'load-path (concat use-package-profile
> "/share/emacs/site-lisp"))
>
> (provide 'use-package-guix)
> #+END_SRC
Finally, I'm not sure if installing packages from my custom local
guix-channel succeeded. I need to retry and investigate more.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
2023-02-02 9:44 ` Mekeor Melire
@ 2023-02-03 2:20 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
2023-02-03 2:31 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
1 sibling, 0 replies; 13+ messages in thread
From: Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution. @ 2023-02-03 2:20 UTC (permalink / raw)
To: Mekeor Melire; +Cc: guix-devel
https://github.com/paperclip4465/use-package-ensure-guix
Thank you for your kind words, I continued working on it and the
repository is here.
> What do you think about naming this package/feature
> "use-package-ensure-guix" and using that as a prefix for all other
> functions and variables -- except for use-package-ensure-guix? I think
> "use-package-ensure-guix" would be a good package name because it's
> pretty much the only (important) function which this packages aims to
> offer. So, …
I ended up going with `use-package-guix` but you are probably right
about using the longer name. I didn't realize that emacs was really a
single namespace lisp and not prefixing your functions was bad practice.
> What is the purpose of this long (progn …)? Could we instead simply
> write (guix-install-package package)?
You are correct, I copied use-package-ensure-elpa to get started and I
didn't know what those extra functions did. It works just as well
without it.
On 2/2/23 04:44, Mekeor Melire wrote:
> 2022-12-27 19:51 mitchellschmeisser@librem.one:
>
>> Mekeor Melire <mekeor@posteo.de> writes:
>>
>> Here is a naive implementation which extends use-package to use guix
>> to ensure packages.
>
> Thank you very much for this great snippet of code. I just
> successfully set it up locally and I'm very happy.
>
> Would you like to create a public Git repository for this
> elisp-package so that we can collaborate on it? If you don't have time
> to do it, I can create a public Git repository (with your copyright
> note; under GPLv3+?; formally owned by an "organization").
>
> Personally, I'm also very much of a noob in things elisp. But
> intuitively, I'd suggest these changes:
>
>> It is a bit annoying at first because it prompts for y/n verification
>> for every package but I think this behavior is desirable.
>
> Personally, I found that behaviour a little tidyous. I'd suggest to
> make it at least configurable.
>
>> #+BEGIN_SRC emacs-lisp
>> (require 'guix)
>> (require 'guix-profiles)
>> (require 'guix-read)
>> (require 'guix-ui-package)
>>
>>
>> (defgroup use-package-guix nil
>
> What do you think about naming this package/feature
> "use-package-ensure-guix" and using that as a prefix for all other
> functions and variables -- except for use-package-ensure-guix? I think
> "use-package-ensure-guix" would be a good package name because it's
> pretty much the only (important) function which this packages aims to
> offer. So, …
>
>> "use-package support for guix" :group 'use-package-ensure)
>>
>> (defcustom use-package-profile (concat (getenv "HOME")
>> "/.emacs.d/guix-profile")
>
> … this variable would then perhaps be renamed into
> "use-package-ensure-guix-profile" or so.
>
>> "Location of use-package guix profile" :type 'string :group
>> 'use-package-guix)
>>
>> (defun guix-package-installed-p (package)
>> (bui-assoc-value package 'installed))
>>
>> (defun canonicalize-name (package-name)
>> "Make sure package name has \"emacs-\" prefix"
>> (if (string-match "^emacs-.+" package-name)
>> package-name
>> (concat "emacs-" package-name)))
>>
>> (defun emacs-package->guix-package (package)
>> "Return guix package from package name"
>> (car (guix-output-list-get-entries use-package-profile 'name
>> (canonicalize-name
>> package))))
>>
>> (defun guix-package-id (package)
>> (bui-entry-non-void-value package 'id))
>
> (This function could be removed, I think.)
>
>> (defun guix-install-package (package)
>> (if (guix-package-installed-p package)
>> t
>> (guix-process-package-actions
>> use-package-profile
>> `((install (,(string-to-number (car (split-string (bui-entry-id
>> package) ":"))) "out"))))
>> (current-buffer)))
>>
>> (defun guix-installed-packages ()
>> (guix-output-list-get-entries use-package-profile 'installed))
>>
>>
>> (defun use-package-ensure-guix (name args _state &optional _no-refresh)
>> (dolist (ensure args)
>> (let ((package
>> (or (and (eq ensure t)
>> (use-package-as-symbol name))
>> ensure)))
>> (when package
>> (when (consp package)
>> (use-package-pin-package (car package) (cdr package))
>> (setq package (car package)))
>>
>> (let ((package (emacs-package->guix-package
>> (use-package-as-string package))))
>> (unless (guix-package-installed-p package)
>> (condition-case-unless-debug err
>> (progn
>> (when (assoc package (bound-and-true-p
>> package-pinned-packages))
>> (package-read-all-archive-contents))
>> (if (assoc package package-archive-contents)
>> (package-install package)
>> (package-refresh-contents)
>> (when (assoc package (bound-and-true-p
>> package-pinned-packages))
>> (package-read-all-archive-contents))
>> (guix-install-package package))
>> t)
>
> What is the purpose of this long (progn …)? Could we instead simply
> write (guix-install-package package)?
>
>>
>> (error (display-warning 'use-package (format
>> "Failed to
>> install %s: %s" name (error-message-string err))
>> :error)))))))))
>
> I'd suggest to miss the "error" label on this message, and rather
> label it as "warning" (which is the default). We could also suggest to
> add ":ensure nil" if it's a built-in feature. (E.g. in case of
> (use-package recentf).)
>
>> ;;;###autoload
>> (add-to-list 'load-path (concat use-package-profile
>> "/share/emacs/site-lisp"))
>>
>> (provide 'use-package-guix)
>> #+END_SRC
>
> Finally, I'm not sure if installing packages from my custom local
> guix-channel succeeded. I need to retry and investigate more.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
2023-02-02 9:44 ` Mekeor Melire
2023-02-03 2:20 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
@ 2023-02-03 2:31 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
1 sibling, 0 replies; 13+ messages in thread
From: Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution. @ 2023-02-03 2:31 UTC (permalink / raw)
To: Mekeor Melire; +Cc: guix-devel
> Finally, I'm not sure if installing packages from my custom local
> guix-channel succeeded. I need to retry and investigate more.
This is a quirk with `emacs-guix`. It doesn't seem to use the pulled
guix and I'm not sure how to fix that.
On 2/2/23 04:44, Mekeor Melire wrote:
> 2022-12-27 19:51 mitchellschmeisser@librem.one:
>
>> Mekeor Melire <mekeor@posteo.de> writes:
>>
>> Here is a naive implementation which extends use-package to use guix
>> to ensure packages.
>
> Thank you very much for this great snippet of code. I just
> successfully set it up locally and I'm very happy.
>
> Would you like to create a public Git repository for this
> elisp-package so that we can collaborate on it? If you don't have time
> to do it, I can create a public Git repository (with your copyright
> note; under GPLv3+?; formally owned by an "organization").
>
> Personally, I'm also very much of a noob in things elisp. But
> intuitively, I'd suggest these changes:
>
>> It is a bit annoying at first because it prompts for y/n verification
>> for every package but I think this behavior is desirable.
>
> Personally, I found that behaviour a little tidyous. I'd suggest to
> make it at least configurable.
>
>> #+BEGIN_SRC emacs-lisp
>> (require 'guix)
>> (require 'guix-profiles)
>> (require 'guix-read)
>> (require 'guix-ui-package)
>>
>>
>> (defgroup use-package-guix nil
>
> What do you think about naming this package/feature
> "use-package-ensure-guix" and using that as a prefix for all other
> functions and variables -- except for use-package-ensure-guix? I think
> "use-package-ensure-guix" would be a good package name because it's
> pretty much the only (important) function which this packages aims to
> offer. So, …
>
>> "use-package support for guix" :group 'use-package-ensure)
>>
>> (defcustom use-package-profile (concat (getenv "HOME")
>> "/.emacs.d/guix-profile")
>
> … this variable would then perhaps be renamed into
> "use-package-ensure-guix-profile" or so.
>
>> "Location of use-package guix profile" :type 'string :group
>> 'use-package-guix)
>>
>> (defun guix-package-installed-p (package)
>> (bui-assoc-value package 'installed))
>>
>> (defun canonicalize-name (package-name)
>> "Make sure package name has \"emacs-\" prefix"
>> (if (string-match "^emacs-.+" package-name)
>> package-name
>> (concat "emacs-" package-name)))
>>
>> (defun emacs-package->guix-package (package)
>> "Return guix package from package name"
>> (car (guix-output-list-get-entries use-package-profile 'name
>> (canonicalize-name
>> package))))
>>
>> (defun guix-package-id (package)
>> (bui-entry-non-void-value package 'id))
>
> (This function could be removed, I think.)
>
>> (defun guix-install-package (package)
>> (if (guix-package-installed-p package)
>> t
>> (guix-process-package-actions
>> use-package-profile
>> `((install (,(string-to-number (car (split-string (bui-entry-id
>> package) ":"))) "out"))))
>> (current-buffer)))
>>
>> (defun guix-installed-packages ()
>> (guix-output-list-get-entries use-package-profile 'installed))
>>
>>
>> (defun use-package-ensure-guix (name args _state &optional _no-refresh)
>> (dolist (ensure args)
>> (let ((package
>> (or (and (eq ensure t)
>> (use-package-as-symbol name))
>> ensure)))
>> (when package
>> (when (consp package)
>> (use-package-pin-package (car package) (cdr package))
>> (setq package (car package)))
>>
>> (let ((package (emacs-package->guix-package
>> (use-package-as-string package))))
>> (unless (guix-package-installed-p package)
>> (condition-case-unless-debug err
>> (progn
>> (when (assoc package (bound-and-true-p
>> package-pinned-packages))
>> (package-read-all-archive-contents))
>> (if (assoc package package-archive-contents)
>> (package-install package)
>> (package-refresh-contents)
>> (when (assoc package (bound-and-true-p
>> package-pinned-packages))
>> (package-read-all-archive-contents))
>> (guix-install-package package))
>> t)
>
> What is the purpose of this long (progn …)? Could we instead simply
> write (guix-install-package package)?
>
>>
>> (error (display-warning 'use-package (format
>> "Failed to
>> install %s: %s" name (error-message-string err))
>> :error)))))))))
>
> I'd suggest to miss the "error" label on this message, and rather
> label it as "warning" (which is the default). We could also suggest to
> add ":ensure nil" if it's a built-in feature. (E.g. in case of
> (use-package recentf).)
>
>> ;;;###autoload
>> (add-to-list 'load-path (concat use-package-profile
>> "/share/emacs/site-lisp"))
>>
>> (provide 'use-package-guix)
>> #+END_SRC
>
> Finally, I'm not sure if installing packages from my custom local
> guix-channel succeeded. I need to retry and investigate more.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-02-03 2:32 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-12-18 1:54 Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm Mekeor Melire
2022-12-18 8:11 ` Liliana Marie Prikler
2022-12-19 10:15 ` Andrew Tropin
2022-12-20 9:45 ` Mekeor Melire
2022-12-20 14:56 ` Andrew Tropin
2022-12-20 9:16 ` Mekeor Melire
2022-12-20 15:06 ` Andrew Tropin
2022-12-19 10:42 ` zimoun
2022-12-28 0:51 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
2023-02-02 9:44 ` Mekeor Melire
2023-02-03 2:20 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
2023-02-03 2:31 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
[not found] <875ydxi4xn.fsf@posteo.de>
2022-12-27 18:52 ` Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.