* NonGNU ELPA: New package: taxy.el
@ 2021-08-26 20:20 Adam Porter
2021-08-26 22:32 ` Stefan Monnier
0 siblings, 1 reply; 5+ messages in thread
From: Adam Porter @ 2021-08-26 20:20 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
Hi Stefan, et al,
I'd like to submit taxy.el to NonGNU ELPA:
https://github.com/alphapapa/taxy.el
A quick description, from the readme:
This library provides a programmable way to classify arbitrary objects
into a hierarchical taxonomy. (That’s a lot of fancy words to say that
this lets you put things in nested groups.)
Helpful features include:
Dynamic taxonomies
Objects may be classified into hierarchies automatically defined
at runtime based on their attributes.
Reusable taxonomies
Taxonomy definitions may be stored in variables and reused in
other taxonomies’ descendant groups.
Please see the attached patch for the nongnu.git repo:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-taxy-Add-Package.patch --]
[-- Type: text/x-diff, Size: 784 bytes --]
From db46d10ec6e67332a4029c0e1805ca24a59acc77 Mon Sep 17 00:00:00 2001
From: Adam Porter <adam@alphapapa.net>
Date: Thu, 26 Aug 2021 14:25:33 -0500
Subject: [PATCH] * elpa-packages (taxy) Add Package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index b7d4a4b..e9b76a2 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -179,6 +179,9 @@
;; https://github.com/Fuco1/smartparens/releases/tag/1.11.0
:version-map ((nil "1.11.0" "4873352b5d0a1c5142658122de1b6950b8fe7e4d")))
+ ("taxy" :url "https://github.com/alphapapa/taxy.el.git"
+ :ignored-files ("taxy-magit-section.el"))
+
("tuareg" :url "https://github.com/ocaml/tuareg.git")
("web-mode" :url "https://github.com/fxbois/web-mode"
--
2.7.4
[-- Attachment #3: Type: text/plain, Size: 1190 bytes --]
Following the nongnu README.org file, I was unable to test the "make
build/taxy" step, because apparently my version of git doesn't have the
"--no-track" argument to the "git worktree" command (and upgrading git
manually is more than I want to do at the moment ;). But I assume that
it will work correctly, because everything seems to be in order.
Assuming this is acceptable, I have a couple of quick questions:
1. I didn't see anything about "externals" in the nongnu readme.
Forgive me, because this has probably been rehashed many times here, but
do I need to specify that manually, or is that the default for the
nongnu repo? I do intend to maintain the package in my own repo.
2. I currently have the version header on "0.1-pre". Do I need to use
a "non-pre" version number in order for the package to be built and
published on (nongnu) ELPA? I'm accustomed to tagging a "non-pre"
version number after the code has settled for a while, but I never
intentionally push anything to the master branch that is unsuitable for
use (i.e. when using MELPA). If this is the case on ELPA, I'll just
need to iterate version numbers a bit more often, which is no problem.
Thanks,
Adam
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: NonGNU ELPA: New package: taxy.el
2021-08-26 20:20 NonGNU ELPA: New package: taxy.el Adam Porter
@ 2021-08-26 22:32 ` Stefan Monnier
2021-08-26 22:56 ` Adam Porter
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2021-08-26 22:32 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
> I'd like to submit taxy.el to NonGNU ELPA:
Why not GNU ELPA?
> Following the nongnu README.org file, I was unable to test the "make
> build/taxy" step, because apparently my version of git doesn't have the
> "--no-track" argument to the "git worktree" command (and upgrading git
> manually is more than I want to do at the moment ;). But I assume that
> it will work correctly, because everything seems to be in order.
Sorry 'bout that dependency. I could try and lift it, but then again
I had to upgrade the `git` on `elpa.gnu.org` because some of the
commands used hit bugs that caused it crash and those uses are hard to
eliminate, so I'm not sure it's worth the effort.
I checked and your recipe seems to work fine, yes.
> 1. I didn't see anything about "externals" in the nongnu readme.
> Forgive me, because this has probably been rehashed many times here, but
> do I need to specify that manually, or is that the default for the
> nongnu repo? I do intend to maintain the package in my own repo.
That's the assumption when you have `:url "...."` in the spec, yes.
> 2. I currently have the version header on "0.1-pre". Do I need to use
> a "non-pre" version number in order for the package to be built and
> published on (nongnu) ELPA?
Yes. The "0.1-pre" version will still appear in the ..-devel archive
(where we always build the latest revision regardless of the version
number), but not in the main one.
Stefan
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NonGNU ELPA: New package: taxy.el
2021-08-26 22:32 ` Stefan Monnier
@ 2021-08-26 22:56 ` Adam Porter
2021-08-27 0:11 ` Stefan Monnier
0 siblings, 1 reply; 5+ messages in thread
From: Adam Porter @ 2021-08-26 22:56 UTC (permalink / raw)
To: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I'd like to submit taxy.el to NonGNU ELPA:
>
> Why not GNU ELPA?
Well, I'm not strictly opposed to that, but I'm not sure if I want to
require copyright assignment to accept contributions to it. Of course,
I understand why Emacs itself does so, and I tend to agree with that,
but for my own packages, I'm not sure if it would be worth it.
For example, I maintain a variety of Emacs-related packages, and none of
them require CA. So what if, several months from now, someone proposed
a contribution to taxy.el, and I forgot to ask for CA (because none of
my other packages do, and I'm not in the habit of even thinking about
that), and then it turned out they were unable to sign it? Would I be
in trouble, or would the package be?
Anyway, if you want to convince me to use GNU ELPA instead, I'm willing
to listen. :)
>> Following the nongnu README.org file, I was unable to test the "make
>> build/taxy" step, because apparently my version of git doesn't have the
>> "--no-track" argument to the "git worktree" command (and upgrading git
>> manually is more than I want to do at the moment ;). But I assume that
>> it will work correctly, because everything seems to be in order.
>
> Sorry 'bout that dependency. I could try and lift it, but then again
> I had to upgrade the `git` on `elpa.gnu.org` because some of the
> commands used hit bugs that caused it crash and those uses are hard to
> eliminate, so I'm not sure it's worth the effort.
Of course, no problem. I'll get mine upgraded at some point.
>> 1. I didn't see anything about "externals" in the nongnu readme.
>> Forgive me, because this has probably been rehashed many times here, but
>> do I need to specify that manually, or is that the default for the
>> nongnu repo? I do intend to maintain the package in my own repo.
>
> That's the assumption when you have `:url "...."` in the spec, yes.
Great, thanks.
>> 2. I currently have the version header on "0.1-pre". Do I need to use
>> a "non-pre" version number in order for the package to be built and
>> published on (nongnu) ELPA?
>
> Yes. The "0.1-pre" version will still appear in the ..-devel archive
> (where we always build the latest revision regardless of the version
> number), but not in the main one.
That sounds good to me, thanks. I'll probably tag a 0.1 soon enough.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NonGNU ELPA: New package: taxy.el
2021-08-26 22:56 ` Adam Porter
@ 2021-08-27 0:11 ` Stefan Monnier
2021-08-27 0:47 ` Adam Porter
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2021-08-27 0:11 UTC (permalink / raw)
To: Adam Porter; +Cc: emacs-devel
>> 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.
Stefan
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NonGNU ELPA: New package: taxy.el
2021-08-27 0:11 ` Stefan Monnier
@ 2021-08-27 0:47 ` Adam Porter
0 siblings, 0 replies; 5+ messages in thread
From: Adam Porter @ 2021-08-27 0:47 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-08-27 0:47 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-08-26 20:20 NonGNU ELPA: New package: taxy.el Adam Porter
2021-08-26 22:32 ` Stefan Monnier
2021-08-26 22:56 ` Adam Porter
2021-08-27 0:11 ` Stefan Monnier
2021-08-27 0:47 ` Adam Porter
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.