unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Fredrik Salomonsson <plattfot@posteo.net>
To: Ricardo Wurmus <rekado@elephly.net>, help-guix@gnu.org
Subject: Re: Emacs use-package: Guix backend?
Date: Sat, 19 Dec 2020 16:10:42 -0800	[thread overview]
Message-ID: <87k0tdibgd.fsf@posteo.net> (raw)
In-Reply-To: <87h7oim8ro.fsf@elephly.net>


Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> I recently moved all my Emacs packages to a separate profile, which is
> controlled by a manifest that’s generated from my init.org configuration
> file.  I like this, because I can separately upgrade packages from my
> main profile and keep my Emacs configuration self-contained.
>
> What still annoys me, though, is that package installation is separate
> from configuration.  I don’t really want to be forced to update the
> manifest at the top of my init.org before I can configure the package
> somewhere at the bottom of the init.org.
>
> The “use-package” macro was designed to allow for both installation and
> configuration in the same place.  By default it uses package.el to
> install packages when they aren’t available yet.  I’d like to use
> “use-package”, but I’d like it to install packages with Guix and also
> install to a separate Guix profile, preferably via a manifest.
>
> Package managers are supposed to override “use-package-ensure-function”
> and/or “use-package-pre-ensure-function” to use something other than
> package.el.
>
> Before I embark on this journey, do any of you have travel reports to
> share?

My 2 cents.

I got multiple profiles; one for emacs, nyxt, git and guile for example.
I wrote a small bash script to make it easy for me to upgrade all of
them or just a subset. What I like about this is that upgrading emacs
and all of its packages are the same as upgrading any of the other
profiles. I.e. I don't have to remember to run
`list-packages` -> `U` -> `x` to update my emacs packages anymore. Plus
I get the bonus of anything goes wrong I can just rollback the emacs
profile.

My emacs manifest is completely decoupled from my configuration. There
are potential of them becoming out of sync. But in practice I haven't
notice anything of that. I haven't found it annoying (yet) to update my
emacs manifest before adding the configuration. Mostly because my
package configuration has been quite stable. It's just recently I've
been starting testing some new packages (after seeing all the cool stuff
from the emacsconf).

> Do you think this is worth doing?

Yes, would be great to have use-package directly feed the manifest and
have some tighter coupling between the configuration and guix.

There are some speed bumps that I can see, one being for example
emacs-flymake-shellcheck does not give you shellcheck so in my manifest
I list both emacs-flymake-shellcheck and shellcheck for that to work.
Maybe keyword-extension[0] can handle cases like these? I.e. you have a
keyword where you can specify external dependencies. Something like:

(use-package flymake-shellcheck
  :guix-install '("shellcheck"))

[0] https://github.com/jwiegley/use-package/tree/master#keyword-extensions

Also, at least for me, I would still like to be able to upgrade/rollback
the emacs profile together with the rest of guix. Instead of that being
yet another step to update your whole system.

> If so, where could we add this feature so that all Guix users benefit
> from it? Emacs-Guix?

That is a good question :). Emacs-Guix seems like a good fit to me as it
already has the logic to talk to guix from emacs.

-- 
s/Fred[re]+i[ck]+/Fredrik/g


  reply	other threads:[~2020-12-20  0:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-19  9:42 Emacs use-package: Guix backend? Ricardo Wurmus
2020-12-20  0:10 ` Fredrik Salomonsson [this message]
2020-12-20  7:24 ` zimoun
  -- strict thread matches above, loose matches on Subject: below --
2021-01-01  4:03 John Soo

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=87k0tdibgd.fsf@posteo.net \
    --to=plattfot@posteo.net \
    --cc=help-guix@gnu.org \
    --cc=rekado@elephly.net \
    /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.
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).