[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using package.el from site-start
From: |
Stefan Monnier |
Subject: |
Re: Using package.el from site-start |
Date: |
Sat, 24 Feb 2024 12:04:39 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hi Spencer,
> I would like to be able to use packages installed into site-lisp/elpa
> (which is added to package-directory-list) in my site-start.el. But I'm
> not sure how in site-start.el I can activate the packages installed into
> site-lisp/elpa without interfering with later customization by users
> which might, e.g., change package-user-dir.
I think "you can't". I mean: you can, but you have to choose between
exposing to `package.el` the fact that those packages are activated (and
interfering with the users's later customizations), or not exposing it
and then have `package.el` *re*activate them later with potentially
undesirable side effects.
> If I call (package-initialize) in site-start.el,
First things, first: if you encounter the need to call
`package-initialize`, please report it as a bug. The function that is
relevant for your use case (that you might want to call) is
`package-activate-all`.
[ `package-initialize` is about making `package.el` ready for things
like `list-packages` or `package-install` and should be called
automatically by the code that needs it. For the subject under
discussion not only you should not need to call it, but nothing should
execute it for you either. ]
> that will activate the site-lisp/elpa packages, but it will prevent
> users from using early-init.el to customize the package system.
They would still be able to customize the package system, but of course
some of those customization could fail to have any effect because they've
already been used 🙁
[ E.g. it's difficult to *de*activate a package after it's been
activated. ]
> Also, if possible, I would like to use the package-quickstart-file
> functionality to speed up activating the packages in site-lisp/elpa.
The current design of `package-quickstart-file` is that it's a single
file that tries to bring Emacs to the "final" state of the user's
config, so it would usually include your site-wide packages along with
any other package they have.
You can load the user's quickstart file from your site-start
(`package-activate-all` will do that for you, by default), but then it
may activate additional packages which the rest of your `site-start.el`
doesn't expect, and it may also fail to activate some packages which
your `site-start.el` does expect.
I suggest the following:
- Use a dedicated "dummy" user account.
- Configure it to be vanilla so it only has your site-start/elpa in its
`package-directory-list` and that it has activated all those packages.
- `M-x package-quickstart-refresh RET`.
- cp ~dummy/.emacs.d/package-quickstart.el* .../site-start/elpa/
Then in `site-start.el` do:
(load ".../site-start/elpa/package-quickstart")
Of course, you'll have to redo it on a regular basis (i.e. whenever the
set of packages in `site-start/elpa/` changes, or whenever the
`...-autoloads.el` file of one of those packages changes), so you'll
probably want to script it.
Keep us posted about problems you encounter with such a setup,
Stefan