emacs-devel
[Top][All Lists]
Advanced

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

Re: Adding use-package to core


From: Philip Kaludercic
Subject: Re: Adding use-package to core
Date: Sat, 19 Nov 2022 10:09:37 +0000

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: spwhitton@spwhitton.name,  luangruo@yahoo.com,  emacs-devel@gnu.org,
>>   xenodasein@tutanota.de
>> Date: Sat, 19 Nov 2022 07:33:30 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> What would the criteria for inclusion be like?
>> >
>> > Packages that we'd like to have in Emacs, but for some reason are on
>> > ELPA instead.  This would allow packages like Magit, Org, project.el,
>> > and maybe others to stay only on ELPA.  
>> 
>> 1. project.el and Org is already included, even developed in Emacs?
>
> The intent was to leave them only on ELPA when the way of including
> ELPA packages in a release is figured out.  (And Org is definitely NOT
> developed in Emacs.)

Of course.

>> 2. Are we talking about GNU ELPA or both NonGNU ELPA and GNU ELPA.
>
> GNU ELPA only.

OK, but then again, what to do about Magit being on NonGNU ELPA.

>> Perhaps we can take a look at the results of the Emacs Survey, when that
>> comes out later this month and collect a list of popular contenders?
>
> We could do that, but until we have a reliable way of including ELPA
> packages in a release (which should include the solution for how to
> upgrade such packages after the released Emacs is installed on the
> user's machine), doing these secondary jobs is IMO just a waste of
> time and energy.  For example, if the solutions are far away in the
> future, the list of contenders you collect now will be outdated by
> then, and will need to be redone anew.
>
> The issues we are touching here were all discussed in the past, and
> the difficulties that need to be resolved were described and also
> discussed.  It's nothing new, and I don't think anything's changed
> since those discussions, we are still where we were back then wrt our
> ability to include ELPA packages.

What exactly is the complication here?  Wouldn't it be possible to have
a "contrib"/"elpa"/... directory under lisp with ELPA packages that are
prepared before packaging?  Or should these packages be moved into the
core?  Would using fancy tricks like git worktrees, as done by
elpa-admin be a possible approach to tackle the issue?



reply via email to

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