Re: policy discussion on bundling ELPA packages in the emacs tarball

[Phillip Lord <phillip.lord@russet.org.uk>]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Phillip Lord <phillip.lord@russet.org.uk> writes:
>
> which is 4 years old, but indicates that mixing worktrees and submodules
> was an issue then.

It's marked as a bug on the git worktrees manual (right at the end).

>
> I'll have to test some stuff. If the submodules cannot be worktrees,
> then I think we have to abandon this approach. Although maybe using
> --depth=1 (or some small number) would be acceptable.
>
>> My own abortive attempt to achieve ELPA bundled packages
>> (https://git.savannah.gnu.org/cgit/emacs.git/log/?h=feature/core-elpa-by-copy),
>> solved one of these two problems -- a single ELPA git repo, but still
>> duplicated bundled packages in each worktree.
>
> I'll look at that.

To caveat, I wouldn't necessarily put this forward as working
solution. It felt kludgey then and it feels so now. I stopped working on
it because of time, though not because it didn't work.


>> Two, I can live with the submodule update if I have to, but this will
>> have to be done on each Worktree I guess. Why not add `configure
>> --with-elpa`
>>
> https://git.savannah.gnu.org/cgit/emacs.git/log/?h=feature/core-elpa-by-copy
>
> I'll have to look at that.
>
> But "copy" implies that the git information is lost, so you can't edit
> the copy and push the changes. That won't do.

Yes, that's the flaw, and it's a fairly big one. If you wanted to edit,
and commit that would require checking out from the ELPA repo, updating
the pointer on the Emacs tree and then checking back in again. This
sounds clunky, although in practice, the number of times you need to
edit a package in tree would be small, I think. I mean, it's the
workflow you have at the moment for ELPA packages right? If you have a
test Emacs and install an ELPA package, you don't want to edit the
source of that ELPA package.

I solve this problem for my own packages by not installing them from
ELPA, but from their git repos. This means normal users and me as
developer have a different set up.

straight.el solves this problem in a more principled way; the package is
the git repo, but then the package manager is completely dependent on
git.

>> Three, out of source builds would I presume include the submodule in the
>> main git tree, not in the out of source location?
>
> Yes; with submodules, 'make build' (out of source or in source) doesn't use
> git to retrieve files, just the filesystem.

Yes. My system uses git archive to retrieve files during the build. I
seem to remember putting an option to have make clone ELPA also,
although that was configurable for exactly the reason we are discussing;
I wanted one copy of ELPA not lots. But, a full git repo build of Emacs
would require git on the build machine. I figured that wasn't a problem
because, well, if you have a git checkout on that machine, then you
probably have git.


> With the alternative "only in elpa" approach, 'make build' will have to
> know where the local elpa source directory is; it should still not use
> git to retrieve files. For building a tarball, step one is get emacs and
> elpa checked out to the right versions, then invoke 'make build'.

Yes. My version doesn't use a check out of ELPA, so it can take source
for different packages from different versions of the same branch.

Phil