Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Mekeor Melire]

[-- 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")))

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Liliana Marie Prikler]

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

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Andrew Tropin]

[-- 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 --]

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[zimoun]

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

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Mekeor Melire]

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.

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Mekeor Melire]

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!

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Andrew Tropin]

[-- 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 --]

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Andrew Tropin]

[-- 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 --]

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.]

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).

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.]

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

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Mekeor Melire]

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.

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.]

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.

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution.]

> 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.