[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: policy discussion on bundling ELPA packages in the emacs tarball - t
From: |
Stephen Leake |
Subject: |
Re: policy discussion on bundling ELPA packages in the emacs tarball - take 2 |
Date: |
Fri, 29 Jan 2021 16:07:16 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (windows-nt) |
Phillip Lord <phillip.lord@russet.org.uk> writes:
> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> Attached is an updated version of emacs/admin/notes/elpa, describing a
>> proposal for bundling ELPA packages in the emacs distribution.
>>
>> I believe I have included all the recent discussions.
>>
>> I think I figured out a way to resolve the submodles vs worktrees
>> dilemma; each emacs developer can choose. If they don't execute any
>> submodule commands, they can use worktrees.
>
> That will be a significant help, actually. I presume that any build
> would be missing bundled packages?
I don't follow.
If you mean "a build from an emacs directory tree", then it will have
whatever the developer checked out into that tree.
If they did "git clone <emacs> --recurse-submodules", then the build
will have the bundled packages.
If they left --recurse-submodules off the clone, but later did either:
git submodule update --reference . --init
or:
./checkout_git_elpa_worktrees.sh
then the build will have the bundled packages.
The last option is indented for your Windows packaging workflow; it uses
git worktrees instead of submodules.
If they do neither of these options, the build will not have the bundled
packages.
> For me, this would not be a hassle because I'll just set it up so they
> install from ELPA on first use.
This is with your emacs user hat on, I guess. Yes, using a build from an
emacs directory tree without bundled packages would require getting
those packages via M-x list-packages (or equivalent).
> It would still break my windows packaging scripts which use worktrees,
It should not, as described above.
--
-- Stephe