emacs-devel
[Top][All Lists]
Advanced

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

Re: NonGNU ELPA: New package: taxy.el


From: Adam Porter
Subject: Re: NonGNU ELPA: New package: taxy.el
Date: Thu, 26 Aug 2021 19:47:03 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Why not GNU ELPA?
> [...]
>> Anyway, if you want to convince me to use GNU ELPA instead, I'm willing
>> to listen.  :)
>
> The way I see NonGNU ELPA is for packages which we Emacs maintainers
> would like to see included in Emacs because they're important for the
> whole Emacs community, but for some reason we were not able to collect
> the needed paperwork.  At least, that was the motivation behind the
> creation of the NonGNU ELPA archive.
>
> taxy.el fails this test on 2 counts:
> 1- we already have the paperwork.
> 2- while it may be a handy package and may yet develop into
>    a cornerstone of Emacs, there aren't hordes of users
>    or packages that depend on it currently.
>
> Admittedly, some of the packages that were added lately to NonGNU also
> fail the "importance" test, so it's probably not as important a criteria
> as I thought it is.

Well, I guess I wouldn't mind having it in ELPA instead of non-GNU
ELPA.

However, I like the idea of having ELPA automatically pull changes from
my repo periodically, rather than having to push to a branch in the ELPA
repo.  I thought that to be possible, having tried to follow recent
conversations about ELPA here, but reading the ELPA.git/README now,
IIUC, that workflow is not supported for ELPA, only for non-GNU ELPA.
Is that right?  Or have I wildly misunderstood?  :)

Also, I'm keeping a few extra source files in the repo at the moment:

- Some example applications in "examples/*.el", which I'll refer to in
  the documentation.

- A magit-section-using library in "taxy-magit-section.el", which may or
  may not be suitable for publishing as a separate package at some
  point.

Should these be included in the package so, e.g. users could refer to
them from the Info manual, or should they be excluded, since they won't
typically be loaded?  (I'll add them to ".elpaignore" if they should be
excluded, so I won't have to update the package recipe in ELPA itself
later.)

Thanks for your help.




reply via email to

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