[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Phillip Lord
Subject: Re: Core ELPA was: Testing fontification, indentation, and buffer manipulation
Date: Sun, 03 Mar 2019 17:52:55 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.92 (gnu/linux)

There has been a lot of discussion about this before. But it stalled
because we didn't have an implementation; this is at least something
that we can talk about concretely.

Richard Stallman <address@hidden> writes:
>   > clones the Emacs repository. When you build it (by default) the Emacs
>   > build process automatically clones the ELPA reposistory and takes the
>   > files that it needs from there.
> That avoids the problem I thought I saw, but what is the purpose?  I
> thought the idea of ELPA is that a user would get ELPA packages when perse
> wants them -- they would not be preloaded.

Perhaps. An alternative, though, would be to reduce the size of Emacs as
a monolithic entity and have many more packages that are distributed via
ELPA. At the moment, the slow release cycle of Emacs means that many
packages are only updated on a two yearly basis.

It's also possible that the large number of packages in core Emacs is
also responsible for the slow release cycle.

> If installing Emacs doesn't require a local copy of ELPA, building
> Emacs should not need one.

Building Emacs requires lots of things that installing does not.

> Is this a way of handling a few packages that are included in Emacs
> distros, if we maintain them in ELPA?  It makes a kind of sense for
> that case, but I would expect that those testing and making Emacs
> releases would need more control over which versions of packages are
> included in the release.

Yes, although as I say, with the intention of enabling more packages to
be developed in this way. I'm not sure how many packages are currently
included in both repos (org and seq for sure).

This build system provides complete control over which versions are
included in the release; so I agree with you there.

>   > My build process simply runs git fetch when it thinks it needs to. Where
>   > the fetch will come from (if anywhere) can be configured where the
>   > developer wants. So, it's still possible to isolate yourself totally
>   > from the main ELPA repo.
> It is one more thing that could trip people up, those who are not used
> to it.  They would forget to do this and the build would surprise them.
> In my case, I might fetch master from the Emacs repo, then build the
> next day while having no network connection.  So it would fail.

Yes. Or, rather, there are circumstances under which it would
fail. Currently, it's a configure option, though. So you could still
build without.

It's also worth mentioning that you perhaps see this as more of a
problem because your life is unusual. I am rarely without a network
connection, even when travelling. I suspect this is the same for most.

> For all these reasons, it would be better to copy these programs
> into the Emacs repo, and just not edit them there -- only update
> from the ELPA repo when appropriate.

I think this is wrong. Having stuff which is not really source (i.e. it
is not the prefered location for editing) in a repo does not really make
sense. org-mode, for example, is currently in three repos (it's own,
ELPA and core). It's not something a route that you would really want to
go down; org-mode does it AFAICT only because of the advantages of being
in the default download of Emacs.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]