unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mekeor Melire <mekeor@posteo.de>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: Andrew Tropin <andrew@trop.in>, guix-devel@gnu.org
Subject: Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
Date: Tue, 20 Dec 2022 09:16:47 +0000	[thread overview]
Message-ID: <87edsuh0i9.fsf@posteo.de> (raw)
In-Reply-To: <cf5ccd4590849576eb20d2e9e1a105ea3640d4e9.camel@gmail.com>

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.


  parent reply	other threads:[~2022-12-20 10:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87edsuh0i9.fsf@posteo.de \
    --to=mekeor@posteo.de \
    --cc=andrew@trop.in \
    --cc=guix-devel@gnu.org \
    --cc=liliana.prikler@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).