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