Re: Core ELPA was: Testing fontification, indentation, and buffer manipulation

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>> I'm unconvinced. I think a build should be repeatable. Imagine bisecting
>> a bug that has come up in an ELPA package when you are not sure whether
>> it's the package or Emacs core that has broken things.
>
> That's already a problem with Elisp packages (whether from GNU ELPA or
> elsewhere), so the fact that we bundle some of them doesn't make much of
> a difference in this respect.

It is, but, now that ELPA package will be in the tarball download; I
think when someone says "bug X, affecting package Y, in Emacs-26.Z" that
should give you enough information to try and reproduce the error.

Without a repeatable build, you will also need to know what verison
package Y is, if and only if it is a "core ELPA" package.


> Dependencies between them *should* be limited so that GNU ELPA packages
> can be used with various Emacs versions (and vice-versa).

I think that this is a necessity at the moment. My own feeling is that
ELPA/package.el should support Emacs versions -- that it should be
possible to publish an ELPA package to a specific version of Emacs. That
is for the future however.


>>> I think on Emacs `master` we won't want to use fixed SHAs but will just
>>> use whatever's on `master` of elpa.git.  On the release branch, we'll
>>> probably want to be more specific, using corresponding branches.
>> That might mean multiple branches of master which would produce a very
>> cluttered namespace. The problem is that ELPA currently uses a different
>> (non git) mechanism to identify the current version of every package; so
>> you can't identify this from git metadata (except for SHA!).
>
> I don't know what you mean.  A branch/tag is just a name for an SHA, so
> I can't see why a branch/tag wouldn't work where an SHA does.

This is how a tag is implemented not what it is. A tag is a meaningful
name, living in a single namespace for an entire repository, which can
refer to different versions over time. A SHA key is not meaningful,
which while it lives in a single namespace has been written to attempt
to be world-unique, and cannot refer to different versions over time.


> In terms of namespace, we'd simply use an appropriate naming scheme,
> of course.

I have extensive experience with naming schemes and "simply" is rarely a
term I would apply; especially, in this case, where many packages
inhabit a single namespace. This rules out the obvious scheme of just
using the Emacs version number.

My naming scheme would be to use a stable, meaningless identifier.

Regardless, the code works either way, because as you say an tag is
implemented as an SHA.


>>>> Finally, neither solve the problem -- if a branch or tag is add
>>>> EMACS/elpa/Makefile.in which exists in the ELPA repo, but not in the
>>>> clone on the local machine the build will fail.
>>>
>>> I think the use of branches/tags will make it sufficiently infrequent
>>> that it's not a big deal.  Also the build shouldn't completely fail.
>>
>> Beyond removing the configure option, it will fail at the moment. I
>> could do something else beyond that.  But surely, by default, the build
>> should fail, if something fails?
>
> I think currently I'd want bundled-GNU-ELPA packages to be treated as
> "GNU ELPA packages pre-installed for the user's convenience" rather than
> as "core packages that you can later upgrade via GNU ELPA".
> So it's OK if they can't build: Emacs should still be perfectly usable
> without its bundled-GNU-ELPA packages (which you can later install via
> GNU ELPA anyway).

Currently, to achieve this on a clone of Emacs, you'd have to
reconfigure. With "./configure", my build would not install ELPA
packages and would (when I've written the code!) only produce a single
source tarball. With "./configure --enable-elpa", it would install ELPA
and produce two source tarballs, but would fail to build without ELPA.

Happy to put another mechanism in, but not sure what that would be.


> Maybe in the future, we'll want to allow some bundled-GNU-ELPA packages
> to be more important (e.g. be *necessary* for example because they're
> used by some core Elisp packages), but there's no need to cross that
> bridge now.

Ironically, the package that stimulated this discussion was "assess.el"
which is a testing package. From a user perspective, of course, it makes
no difference but for the developer it's exactly the sort of package
that you would want to make a dependency to many other
packages. Likewise, seq.el (which is why Nicolas wants to move it from
ELPA to core!).

Phil