Re: [ELPA] New package: use-package

Re: [ELPA] New package: use-package

[Payas Relekar]

[-- Attachment #1: Type: text/plain, Size: 96 bytes --]

Payas Relekar <relekarpayas@gmail.com> writes:

Somehow Gmail removed the patch. Attached now.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-use-package-New-package.patch --]
[-- Type: text/x-patch, Size: 1564 bytes --]

From c96ca180028faaada941129d603c715965e471ad Mon Sep 17 00:00:00 2001
From: Payas Relekar <relekarpayas@gmail.com>
Date: Tue, 25 Oct 2022 10:51:57 +0530
Subject: [PATCH] elpa-packages (use-package): New package

---
 elpa-packages | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/elpa-packages b/elpa-packages
index afd9b1a528..4f1a86d6a8 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -86,9 +86,6 @@
   :auto-sync nil)
  ("beacon"		:url "https://github.com/Malabarba/beacon"
   :auto-sync t)
- ;;("bind-key"         :url "https://github.com/jwiegley/use-package"
- ;; :ignored-files ("LICENSE" "doc" "Makefile*" "bind-chords.el" "use-package*")
- ;; :auto-sync t)
  ("blist"		:url "https://gitlab.com/mmemmew/blist"
   :doc "blist.texinfo"
   :readme "README.org"
@@ -739,11 +736,12 @@
   :readme "README.md")
  ("uniquify-files"	:url nil)
  ("url-http-ntlm" 	:url nil)
- ;;("use-package"		:url "https://github.com/jwiegley/use-package"
- ;; :ignored-files ("LICENSE" "bind-*" "use-package-chords.el")
- ;; :doc "use-package.texi"
- ;; :news "NEWS.md"
- ;; :auto-sync t)
+ ("use-package"	:url "https://github.com/jwiegley/use-package"
+  :auto-sync t
+  :ignored-files ("LICENSE" "bind-*" "use-package-chords.el" "use-package-ensure-system-package.el" ".travis.yml")
+  :readme "README.md"
+  :doc "use-package.texi"
+  :news "NEWS.md")
  ("validate"		:url "https://github.com/Malabarba/validate.el")
  ("valign"		:url "https://github.com/casouri/valign")
  ("vc-backup"		:url "https://git.sr.ht/~pkal/vc-backup"
-- 
2.37.3

Re: [ELPA] New package: use-package

[Philip Kaludercic]

Payas Relekar <relekarpayas@gmail.com> writes:

> Payas Relekar <relekarpayas@gmail.com> writes:
>
> Somehow Gmail removed the patch. Attached now.
>
> From c96ca180028faaada941129d603c715965e471ad Mon Sep 17 00:00:00 2001
> From: Payas Relekar <relekarpayas@gmail.com>
> Date: Tue, 25 Oct 2022 10:51:57 +0530
> Subject: [PATCH] elpa-packages (use-package): New package
>
> ---
>  elpa-packages | 14 ++++++--------
>  1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/elpa-packages b/elpa-packages
> index afd9b1a528..4f1a86d6a8 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -86,9 +86,6 @@
>    :auto-sync nil)
>   ("beacon"		:url "https://github.com/Malabarba/beacon"
>    :auto-sync t)
> - ;;("bind-key"         :url "https://github.com/jwiegley/use-package"
> - ;; :ignored-files ("LICENSE" "doc" "Makefile*" "bind-chords.el" "use-package*")
> - ;; :auto-sync t)
>   ("blist"		:url "https://gitlab.com/mmemmew/blist"
>    :doc "blist.texinfo"
>    :readme "README.org"
> @@ -739,11 +736,12 @@
>    :readme "README.md")
>   ("uniquify-files"	:url nil)
>   ("url-http-ntlm" 	:url nil)
> - ;;("use-package"		:url "https://github.com/jwiegley/use-package"
> - ;; :ignored-files ("LICENSE" "bind-*" "use-package-chords.el")
> - ;; :doc "use-package.texi"
> - ;; :news "NEWS.md"
> - ;; :auto-sync t)
> + ("use-package"	:url "https://github.com/jwiegley/use-package"
> +  :auto-sync t
> +  :ignored-files ("LICENSE" "bind-*" "use-package-chords.el" "use-package-ensure-system-package.el" ".travis.yml")

It would be preferable to add files like .travis.yml to a .elpaignore
file in the repository itself.

> +  :readme "README.md"
> +  :doc "use-package.texi"
> +  :news "NEWS.md")
>   ("validate"		:url "https://github.com/Malabarba/validate.el")
>   ("valign"		:url "https://github.com/casouri/valign")
>   ("vc-backup"		:url "https://git.sr.ht/~pkal/vc-backup"

Re: [ELPA] New package: use-package

[Payas Relekar]

Philip Kaludercic <philipk@posteo.net> writes:

> It would be preferable to add files like .travis.yml to a .elpaignore
> file in the repository itself.

Thanks!

I opened a PR upstream with feedback regarding copyright + above.

John can review in his own time.

Meanwhile, my total contributions to use-package now would be +14, -14,
all in commented files, for copyright year modification etc. It is not
clear to me if this will require copyright assignment. Let me know if I
need to get started on that while PR gets reviewed upstream.

Thanks,
Payas
--

Re: [ELPA] New package: use-package

[Philip Kaludercic]

Payas Relekar <relekarpayas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> It would be preferable to add files like .travis.yml to a .elpaignore
>> file in the repository itself.
>
> Thanks!
>
> I opened a PR upstream with feedback regarding copyright + above.

https://github.com/jwiegley/use-package/pull/1005 for anyone wondering.

> John can review in his own time.
>
> Meanwhile, my total contributions to use-package now would be +14, -14,
> all in commented files, for copyright year modification etc. It is not
> clear to me if this will require copyright assignment. Let me know if I
> need to get started on that while PR gets reviewed upstream.

If I were you I'd sign it just to not have to worry about this in the
future.

Re: [ELPA] New package: use-package

[John Wiegley]

>>>>> Payas Relekar <relekarpayas@gmail.com> writes:

> I opened a PR upstream with feedback regarding copyright + above.

> John can review in his own time.

Thank you, Payas, I just returned home from travel and have merged the PR.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] New package: use-package

[Payas Relekar]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]


John Wiegley <johnw@gnu.org> writes:

> Thank you, Payas, I just returned home from travel and have merged the PR.

Thank you John! I opened another PR to bump version so ELPA can detect
new copyright years as per Philip's comment. Apologies for the barrage.

Meanwhile, here is another patch for ELPA with "bind-key.el" and LICENSE
included as per feedback.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-use-package-New-package.patch --]
[-- Type: text/x-patch, Size: 1169 bytes --]

From 644189b60122b289e7d19cf151122fb914ca3f20 Mon Sep 17 00:00:00 2001
From: Payas Relekar <relekarpayas@gmail.com>
Date: Thu, 27 Oct 2022 09:08:33 +0530
Subject: [PATCH] elpa-packages (use-package): New package

---
 elpa-packages | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/elpa-packages b/elpa-packages
index afd9b1a528..ce6f2c402e 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -739,11 +739,12 @@
   :readme "README.md")
  ("uniquify-files"	:url nil)
  ("url-http-ntlm" 	:url nil)
- ;;("use-package"		:url "https://github.com/jwiegley/use-package"
- ;; :ignored-files ("LICENSE" "bind-*" "use-package-chords.el")
- ;; :doc "use-package.texi"
- ;; :news "NEWS.md"
- ;; :auto-sync t)
+ ("use-package"	:url "https://github.com/jwiegley/use-package"
+  :auto-sync t
+  :ignored-files ("bind-*" "use-package-chords.el" "use-package-ensure-system-package.el" ".travis.yml")
+  :readme "README.md"
+  :doc "use-package.texi"
+  :news "NEWS.md")
  ("validate"		:url "https://github.com/Malabarba/validate.el")
  ("valign"		:url "https://github.com/casouri/valign")
  ("vc-backup"		:url "https://git.sr.ht/~pkal/vc-backup"
-- 
2.38.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0001-elpa-packages-bind-key-New-package.patch --]
[-- Type: text/x-patch, Size: 1223 bytes --]

From 2fa0c1fc9df4e61bb5b9344f302e36be38d2e2dd Mon Sep 17 00:00:00 2001
From: Payas Relekar <relekarpayas@gmail.com>
Date: Thu, 27 Oct 2022 09:09:58 +0530
Subject: [PATCH] elpa-packages (bind-key): New package

---
 elpa-packages | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/elpa-packages b/elpa-packages
index ce6f2c402e..62b35f5699 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -86,15 +86,16 @@
   :auto-sync nil)
  ("beacon"		:url "https://github.com/Malabarba/beacon"
   :auto-sync t)
- ;;("bind-key"         :url "https://github.com/jwiegley/use-package"
- ;; :ignored-files ("LICENSE" "doc" "Makefile*" "bind-chords.el" "use-package*")
- ;; :auto-sync t)
  ("blist"		:url "https://gitlab.com/mmemmew/blist"
   :doc "blist.texinfo"
   :readme "README.org"
   :auto-sync t)
  ("bluetooth"		:url "https://gitlab.com/rstocker/emacs-bluetooth"
   :auto-sync t)
+ ("bind-key"		:url "https://github.com/jwiegley/use-package"
+  :main-file "bind-key.el"
+  :ignored-files ("LICENSE" "doc" "Makefile*" "bind-chords.el" "use-package*")
+  :auto-sync t)
  ("bnf-mode"		:url "https://github.com/sergeyklay/bnf-mode")
  ("boxy"		:url "https://gitlab.com/tygrdev/boxy"
   :auto-sync t)
-- 
2.38.0

Re: [ELPA] New package: use-package

[Payas Relekar]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

Turns out I sent old patch files. Here are updated ones.

Thanks John for merging version update PR in, since upstream fixes are
complete we should be good to push to GNU ELPA now.

Payas Relekar <relekarpayas@gmail.com> writes:

> John Wiegley <johnw@gnu.org> writes:
>
>> Thank you, Payas, I just returned home from travel and have merged the PR.
>
> Thank you John! I opened another PR to bump version so ELPA can detect
> new copyright years as per Philip's comment. Apologies for the barrage.
>
> Meanwhile, here is another patch for ELPA with "bind-key.el" and LICENSE
> included as per feedback.
>
> [2. text/x-patch; 0001-elpa-packages-use-package-New-package.patch]...
>
> [3. text/x-patch; 0001-elpa-packages-bind-key-New-package.patch]...


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-use-package-New-package.patch --]
[-- Type: text/x-patch, Size: 1159 bytes --]

From 387453c22a2ec6545f40cdaf54d5a78aef0c018e Mon Sep 17 00:00:00 2001
From: Payas Relekar <relekarpayas@gmail.com>
Date: Thu, 27 Oct 2022 09:08:33 +0530
Subject: [PATCH 1/2] elpa-packages (use-package): New package

---
 elpa-packages | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/elpa-packages b/elpa-packages
index afd9b1a528..794ee75738 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -739,11 +739,12 @@
   :readme "README.md")
  ("uniquify-files"	:url nil)
  ("url-http-ntlm" 	:url nil)
- ;;("use-package"		:url "https://github.com/jwiegley/use-package"
- ;; :ignored-files ("LICENSE" "bind-*" "use-package-chords.el")
- ;; :doc "use-package.texi"
- ;; :news "NEWS.md"
- ;; :auto-sync t)
+ ("use-package"	:url "https://github.com/jwiegley/use-package"
+  :auto-sync t
+  :ignored-files ("bind-*" "use-package-chords.el" "use-package-ensure-system-package.el")
+  :readme "README.md"
+  :doc "use-package.texi"
+  :news "NEWS.md")
  ("validate"		:url "https://github.com/Malabarba/validate.el")
  ("valign"		:url "https://github.com/casouri/valign")
  ("vc-backup"		:url "https://git.sr.ht/~pkal/vc-backup"
-- 
2.38.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-elpa-packages-bind-key-New-package.patch --]
[-- Type: text/x-patch, Size: 996 bytes --]

From 6e5bbb3538b9cff5efc9793df73b53d4f46ba7b5 Mon Sep 17 00:00:00 2001
From: Payas Relekar <relekarpayas@gmail.com>
Date: Thu, 27 Oct 2022 10:54:09 +0530
Subject: [PATCH 2/2] elpa-packages (bind-key): New package

---
 elpa-packages | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/elpa-packages b/elpa-packages
index 794ee75738..78ff0e5a8c 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -86,9 +86,10 @@
   :auto-sync nil)
  ("beacon"		:url "https://github.com/Malabarba/beacon"
   :auto-sync t)
- ;;("bind-key"         :url "https://github.com/jwiegley/use-package"
- ;; :ignored-files ("LICENSE" "doc" "Makefile*" "bind-chords.el" "use-package*")
- ;; :auto-sync t)
+ ("bind-key"		:url "https://github.com/jwiegley/use-package"
+  :main-file "bind-key.el"
+  :ignored-files ("LICENSE" "doc" "Makefile*" "bind-chords.el" "use-package*")
+  :auto-sync t)
  ("blist"		:url "https://gitlab.com/mmemmew/blist"
   :doc "blist.texinfo"
   :readme "README.org"
-- 
2.38.0

Re: [ELPA] New package: use-package

[Payas Relekar]

Re-added emacs-devel. Philip, it appears your replies are dropping
emacs-devel. I noticed at least 1 other occurrence for the same.

Philip Kaludercic <philipk@posteo.net> writes:

> Has the copyright situation for the file been resolved?  Is it even
> necessary to have that file now that the documentation has been
> translated to .texi?  From what I understand the file is responsible for
> exporting the org-mode documentation using Hugo (https://gohugo.io/),
> but that will now automatically be provided by the ELPA build server.
> It might therefore not only be possible to ignore, but also remove the
> file, but I guess that John should make that call.

Indeed John can tell about copyright for this directory and whatever
generated code for it.

--

Re: [ELPA] New package: use-package

[Payas Relekar]

Re-including emacs-devel, as my mail agent seems to be dropping it sometimes

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

>>>     git clone --single-branch git://git.savannah.gnu.org/emacs/elpa.git
>>>     cd elpa
>>>     make
>>
>> I already had elpa.git cloned and yes, it took a while :) Perhaps above
>> step should be recommended default.
>
> Definitely.  Let us know where you got your other "recommended default"
> from so we can fix it.

I got it from here: https://savannah.gnu.org/git/?group=emacs

My chain of progression to this page was:
1. Google GNU ELPA
2. Go here: https://elpa.gnu.org/
3. Gio here:
https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README
4. Ultimately follow "Getting the source" section of README to here:
https://savannah.gnu.org/git/?group=emacs

>>> then fetch your package:
>>>
>>>     make packages/use-package
>>
>> Thanks! I'm not at my machine right now, but my build failed at this
>> point. It may be possible I was missing some implicit dependencies. Are
>> gcc and gnumake enough?
>
> Gcc is definitely not needed.  The above just executes a few Git
> commands to fetch the code.

Thanks! I'll try it out once at my machine.
--

Re: [ELPA] New package: use-package

[Stefan Monnier]

>>> I already had elpa.git cloned and yes, it took a while :) Perhaps above
>>> step should be recommended default.
>>
>> Definitely.  Let us know where you got your other "recommended default"
>> from so we can fix it.
>
> I got it from here: https://savannah.gnu.org/git/?group=emacs
>
> My chain of progression to this page was:
> 1. Google GNU ELPA
> 2. Go here: https://elpa.gnu.org/
> 3. Gio here:
> https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README
> 4. Ultimately follow "Getting the source" section of README to here:
> https://savannah.gnu.org/git/?group=emacs

Thanks, indeed that's not helpful at all, I'll try to improve it.

> Thanks! I'll try it out once at my machine.

Let me know if you encounter difficulties,


        Stefan

Re: [ELPA] New package: use-package

[Payas Relekar]

Re-adding emacs-devel

Payas Relekar <relekarpayas@gmail.com> writes:

> Hi,
>
> Since John gave confirmation for copyrights, I am preparing another PR.
> However, to avoid throwing more non-working commits at John, I thought
> to test it on local first.
>
> For reference, here is my changes:
> https://github.com/jwiegley/use-package/compare/master...bhankas:use-package:master
>
> Then I changed elpa/elpa-packages to point to my clone for use-package
> and tried to build with following:
>
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> First, get the "infrastructure":
>>
>>     git clone --single-branch git://git.savannah.gnu.org/emacs/elpa.git
>>     cd elpa
>>     make
>>
>> then fetch your package:
>>
>>     make packages/use-package
>
> At this point my build is failing with this:
>
> ~~~~
> ~/g/elpa main $ make packages/use-package
> emacs --batch -l admin/elpa-admin.el -f elpaa-batch-archive-update-worktrees use-package
> Cloning branch use-package:
> fatal: 'externals/use-package' is already checked out at '/home/payas/git/elpa/packages/use-package'
>
> ~/g/elpa main $ ls -alh packages/
> total 8.0K
> drwxr-xr-x 2 payas payas 4.0K Nov  3 13:21 .
> drwxr-xr-x 8 payas payas 4.0K Nov  3 13:31 ..
> -rw-r--r-- 1 payas payas    0 Nov  3 13:21 .keep
> ~/g/elpa main ?1 ?
> ~~~~
>
> I believe this is some leftover from previous attempt to build, but
> there is only 1 file in packages/use-directory and it is an empty
> '.keep'
>
> But, I could use some help untangling exactly what is going on here and
> fix it.
>
>> then build your tarballs (they get put into `archive(-devel)/`):
>>
>>     make build/use-package
>>
>> You can also set it up for "in-place use" (along the lines of `package-vc`):
>>
>>     make packages/use-package
>>
>> This last one is the only "normal" make command, which tries to use
>> dependencies to decide what to do, and can be re-run to recompile the
>> modified files.
>
> Thanks,
> Payas


--

Re: [ELPA] New package: use-package

[Payas Relekar]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]


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

> My crystal ball tells me that you had done `make packages/use-package`
> in the past and then you `rm packages/use-package`.  Git doesn't
> automatically discover when you delete such a worktree, so if that's
> what happened
>
>     git worktree prune -v
>
> should fix the problem, after which you can re-try the above command.

You crystal ball was right! After pruning worktree the command worked,
but I am quite confused at the output. I've attached the logs for my
attempt to build, can you please check if I did something incorrectly?

In particular the build command fails because it complains makeinfo is
not available, but I clearly have it in path. Also make after build only
seems to build setup-ox-hugo.el. There are also couple of errors, there
are couple of errors too, and I'm not sure if fixing them is worth it.

My understanding is that we only need to add copyrights to the file
because entire repo is cloned to GNU machines. But even after adding
copyright headers, IMO adding doc/* to :ignored-files is the right thing
to do as it does not serve users directly.


[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 9077 bytes --]

~/g/elpa main $ makeinfo --version
texi2any (GNU texinfo) 6.8

Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

~/g/elpa main $ make build/use-package
emacs --batch -l /home/payas/git/elpa/admin/elpa-admin.el       \
         -f elpaa-batch-make-one-package use-package
Updating worktree in "/home/payas/git/elpa/packages/use-package/"
Updated use-package:
Auto-merging use-package-core.el
Merge made by the 'ort' strategy.
 README.md            | 4 ++--
 use-package-core.el  | 4 ++--
 use-package-tests.el | 7 +++++++
 3 files changed, 11 insertions(+), 4 deletions(-)

======== Building tarball archive-devel/use-package-2.4.4.0.20221103.163652.tar...
Build error for archive-devel/use-package-2.4.4.0.20221103.163652.tar: (error "Error-indicating exit code in elpaa--call-sandboxed:
bwrap: execvp makeinfo: No such file or directory
")
######## Build of package archive-devel/use-package-2.4.4.0.20221103.163652.tar FAILED!!
======== Building tarball archive/use-package-2.4.4.tar...
Build error for archive/use-package-2.4.4.tar: (error "Error-indicating exit code in elpaa--call-sandboxed:
bwrap: execvp makeinfo: No such file or directory
")
######## Build of package archive/use-package-2.4.4.tar FAILED!!

~/g/elpa main $ make packages/use-package
Generating description file packages/use-package/use-package-pkg.el
emacs --batch -l admin/elpa-admin.el                               \
         -f elpaa-batch-generate-autoloads packages/use-package/use-package-autoloads.el
  INFO     Scraping files for loaddefs...
  INFO     Scraping files for loaddefs...done
  GEN      use-package-autoloads.el
Byte compiling packages/use-package/bind-chord.el
Unable to activate package `use-package'.
Required package `bind-key-2.4' is unavailable
Byte compiling packages/use-package/bind-key.el
Unable to activate package `use-package'.
Required package `bind-key-2.4' is unavailable
Byte compiling packages/use-package/doc/setup-ox-hugo.el
Unable to activate package `use-package'.
Required package `bind-key-2.4' is unavailable

In toplevel form:
packages/use-package/doc/setup-ox-hugo.el:192:51: Warning: reference to free variable `ox-hugo-default-lisp-directory'
packages/use-package/doc/setup-ox-hugo.el:215:21: Warning: reference to free variable `org-emphasis-regexp-components'
packages/use-package/doc/setup-ox-hugo.el:222:33: Warning: Unused lexical argument `file'
packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
packages/use-package/doc/setup-ox-hugo.el:230:56: Warning: Unused lexical argument `body'
packages/use-package/doc/setup-ox-hugo.el:238:11: Warning: assignment to free variable `org-confirm-babel-evaluate'
packages/use-package/doc/setup-ox-hugo.el:241:11: Warning: assignment to free variable `org-export-headline-levels'
packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: reference to free variable `org-export-exclude-tags'
packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: assignment to free variable `org-export-exclude-tags'

In end of data:
packages/use-package/doc/setup-ox-hugo.el:238:40: Warning: the function `ox-hugo-org-confirm-babel-evaluate-fn' is not known to be defined.
packages/use-package/doc/setup-ox-hugo.el:218:4: Warning: the function `org-set-emph-re' is not known to be defined.
packages/use-package/doc/setup-ox-hugo.el:208:4: Warning: the function `org-hugo-export-wim-to-md' is not known to be defined.
packages/use-package/doc/setup-ox-hugo.el:75:49: Warning: the function `vc-git-root' is not known to be defined.
make: *** [GNUmakefile:119: packages/use-package/doc/setup-ox-hugo.elc] Error 1

~/g/elpa main ?1 2.7s [2] make build/bind-key
emacs --batch -l /home/payas/git/elpa/admin/elpa-admin.el       \
         -f elpaa-batch-make-one-package bind-key
Cloning branch bind-key:
Preparing worktree (new branch 'externals/bind-key')
branch 'externals/bind-key' set up to track 'origin/externals/bind-key'.
HEAD is now at 0be480ea77 Merge pull request #1009 from andreyorst/face-spec-set-third-argument

======== Building tarball archive-devel/bind-key-2.4.1.0.20221029.145719.tar...
######## Built new package archive-devel/bind-key-2.4.1.0.20221029.145719.tar!
======== Building tarball archive/bind-key-2.4.1.tar...
######## Built new package archive/bind-key-2.4.1.tar!

~/g/elpa main ?1 1.2s ? make packages/bind-key
emacs --batch -Q -l admin/elpa-admin.el \
         -f elpaa-batch-pkg-spec-make-dependencies .pkg-descs.mk
Generating description file packages/bind-key/bind-key-pkg.el
emacs --batch -l admin/elpa-admin.el                               \
         -f elpaa-batch-generate-autoloads packages/bind-key/bind-key-autoloads.el
  INFO     Scraping files for loaddefs...
  INFO     Scraping files for loaddefs...done
  GEN      bind-key-autoloads.el
Byte compiling packages/bind-key/bind-chord.el
Byte compiling packages/bind-key/bind-key.el
Byte compiling packages/bind-key/doc/setup-ox-hugo.el

In toplevel form:
packages/bind-key/doc/setup-ox-hugo.el:1:3: Warning: reference to free variable `-*-'
packages/bind-key/doc/setup-ox-hugo.el:1:7: Warning: reference to free variable `lexical-binding:'
packages/bind-key/doc/setup-ox-hugo.el:169:51: Warning: reference to free variable `ox-hugo-default-lisp-directory'
packages/bind-key/doc/setup-ox-hugo.el:192:21: Warning: reference to free variable `org-emphasis-regexp-components'
packages/bind-key/doc/setup-ox-hugo.el:199:33: Warning: Unused lexical argument `file'
packages/bind-key/doc/setup-ox-hugo.el:201:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
packages/bind-key/doc/setup-ox-hugo.el:201:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
packages/bind-key/doc/setup-ox-hugo.el:207:56: Warning: Unused lexical argument `body'
packages/bind-key/doc/setup-ox-hugo.el:215:11: Warning: assignment to free variable `org-confirm-babel-evaluate'
packages/bind-key/doc/setup-ox-hugo.el:218:11: Warning: assignment to free variable `org-export-headline-levels'
packages/bind-key/doc/setup-ox-hugo.el:219:19: Warning: reference to free variable `org-export-exclude-tags'
packages/bind-key/doc/setup-ox-hugo.el:219:19: Warning: assignment to free variable `org-export-exclude-tags'

In end of data:
packages/bind-key/doc/setup-ox-hugo.el:215:40: Warning: the function `ox-hugo-org-confirm-babel-evaluate-fn' is not known to be defined.
packages/bind-key/doc/setup-ox-hugo.el:195:4: Warning: the function `org-set-emph-re' is not known to be defined.
packages/bind-key/doc/setup-ox-hugo.el:185:4: Warning: the function `org-hugo-export-wim-to-md' is not known to be defined.
packages/bind-key/doc/setup-ox-hugo.el:52:49: Warning: the function `vc-git-root' is not known to be defined.
make: *** [GNUmakefile:119: packages/bind-key/doc/setup-ox-hugo.elc] Error 1
~/g/elpa main ?1 3.5s [2] make packages/use-package

Byte compiling packages/use-package/doc/setup-ox-hugo.el

In toplevel form:
packages/use-package/doc/setup-ox-hugo.el:192:51: Warning: reference to free variable `ox-hugo-default-lisp-directory'
packages/use-package/doc/setup-ox-hugo.el:215:21: Warning: reference to free variable `org-emphasis-regexp-components'
packages/use-package/doc/setup-ox-hugo.el:222:33: Warning: Unused lexical argument `file'
packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
packages/use-package/doc/setup-ox-hugo.el:230:56: Warning: Unused lexical argument `body'
packages/use-package/doc/setup-ox-hugo.el:238:11: Warning: assignment to free variable `org-confirm-babel-evaluate'
packages/use-package/doc/setup-ox-hugo.el:241:11: Warning: assignment to free variable `org-export-headline-levels'
packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: reference to free variable `org-export-exclude-tags'
packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: assignment to free variable `org-export-exclude-tags'

In end of data:
packages/use-package/doc/setup-ox-hugo.el:238:40: Warning: the function `ox-hugo-org-confirm-babel-evaluate-fn' is not known to be defined.
packages/use-package/doc/setup-ox-hugo.el:218:4: Warning: the function `org-set-emph-re' is not known to be defined.
packages/use-package/doc/setup-ox-hugo.el:208:4: Warning: the function `org-hugo-export-wim-to-md' is not known to be defined.
packages/use-package/doc/setup-ox-hugo.el:75:49: Warning: the function `vc-git-root' is not known to be defined.
make: *** [GNUmakefile:119: packages/use-package/doc/setup-ox-hugo.elc] Error 1

Re: [ELPA] New package: use-package

[Philip Kaludercic]

Payas Relekar <relekarpayas@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> My crystal ball tells me that you had done `make packages/use-package`
>> in the past and then you `rm packages/use-package`.  Git doesn't
>> automatically discover when you delete such a worktree, so if that's
>> what happened
>>
>>     git worktree prune -v
>>
>> should fix the problem, after which you can re-try the above command.
>
> You crystal ball was right! After pruning worktree the command worked,
> but I am quite confused at the output. I've attached the logs for my
> attempt to build, can you please check if I did something incorrectly?
>
> In particular the build command fails because it complains makeinfo is
> not available, but I clearly have it in path. Also make after build only
> seems to build setup-ox-hugo.el. There are also couple of errors, there
> are couple of errors too, and I'm not sure if fixing them is worth it.
>
> My understanding is that we only need to add copyrights to the file
> because entire repo is cloned to GNU machines. But even after adding
> copyright headers, IMO adding doc/* to :ignored-files is the right thing
> to do as it does not serve users directly.

I can imagine that replacing "doc/*" with "doc/" might help, as
`elpaa--copyright-files' doesn't appear to do any globing, instead just
tries to find the file using `member' (ie. using a string comparison
and not even `file-equal-p').

> ~/g/elpa main $ makeinfo --version
> texi2any (GNU texinfo) 6.8
>
> Copyright (C) 2021 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> ~/g/elpa main $ make build/use-package
> emacs --batch -l /home/payas/git/elpa/admin/elpa-admin.el       \
>          -f elpaa-batch-make-one-package use-package
> Updating worktree in "/home/payas/git/elpa/packages/use-package/"
> Updated use-package:
> Auto-merging use-package-core.el
> Merge made by the 'ort' strategy.
>  README.md            | 4 ++--
>  use-package-core.el  | 4 ++--
>  use-package-tests.el | 7 +++++++
>  3 files changed, 11 insertions(+), 4 deletions(-)
>
> ======== Building tarball archive-devel/use-package-2.4.4.0.20221103.163652.tar...
> Build error for archive-devel/use-package-2.4.4.0.20221103.163652.tar: (error "Error-indicating exit code in elpaa--call-sandboxed:
> bwrap: execvp makeinfo: No such file or directory
> ")

This is suspicious, where is makeinfo located?  Perhaps you can find out
more if you set the environmental variable "ELPA_DEBUG"?

> ######## Build of package archive-devel/use-package-2.4.4.0.20221103.163652.tar FAILED!!
> ======== Building tarball archive/use-package-2.4.4.tar...
> Build error for archive/use-package-2.4.4.tar: (error "Error-indicating exit code in elpaa--call-sandboxed:
> bwrap: execvp makeinfo: No such file or directory
> ")
> ######## Build of package archive/use-package-2.4.4.tar FAILED!!
>
> ~/g/elpa main $ make packages/use-package
> Generating description file packages/use-package/use-package-pkg.el
> emacs --batch -l admin/elpa-admin.el                               \
>          -f elpaa-batch-generate-autoloads packages/use-package/use-package-autoloads.el
>   INFO     Scraping files for loaddefs...
>   INFO     Scraping files for loaddefs...done
>   GEN      use-package-autoloads.el
> Byte compiling packages/use-package/bind-chord.el
> Unable to activate package `use-package'.
> Required package `bind-key-2.4' is unavailable
> Byte compiling packages/use-package/bind-key.el
> Unable to activate package `use-package'.
> Required package `bind-key-2.4' is unavailable
> Byte compiling packages/use-package/doc/setup-ox-hugo.el
> Unable to activate package `use-package'.
> Required package `bind-key-2.4' is unavailable
>
> In toplevel form:
> packages/use-package/doc/setup-ox-hugo.el:192:51: Warning: reference to free variable `ox-hugo-default-lisp-directory'
> packages/use-package/doc/setup-ox-hugo.el:215:21: Warning: reference to free variable `org-emphasis-regexp-components'
> packages/use-package/doc/setup-ox-hugo.el:222:33: Warning: Unused lexical argument `file'
> packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
> packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
> packages/use-package/doc/setup-ox-hugo.el:230:56: Warning: Unused lexical argument `body'
> packages/use-package/doc/setup-ox-hugo.el:238:11: Warning: assignment to free variable `org-confirm-babel-evaluate'
> packages/use-package/doc/setup-ox-hugo.el:241:11: Warning: assignment to free variable `org-export-headline-levels'
> packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: reference to free variable `org-export-exclude-tags'
> packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: assignment to free variable `org-export-exclude-tags'
>
> In end of data:
> packages/use-package/doc/setup-ox-hugo.el:238:40: Warning: the function `ox-hugo-org-confirm-babel-evaluate-fn' is not known to be defined.
> packages/use-package/doc/setup-ox-hugo.el:218:4: Warning: the function `org-set-emph-re' is not known to be defined.
> packages/use-package/doc/setup-ox-hugo.el:208:4: Warning: the function `org-hugo-export-wim-to-md' is not known to be defined.
> packages/use-package/doc/setup-ox-hugo.el:75:49: Warning: the function `vc-git-root' is not known to be defined.
> make: *** [GNUmakefile:119: packages/use-package/doc/setup-ox-hugo.elc] Error 1

The ignored files are just not included into the tarball (see
`elpaa--make-one-tarball-1' in elpa-admin.el), but they are still byte
compiled AFAIK.

> ~/g/elpa main ?1 2.7s [2] make build/bind-key
> emacs --batch -l /home/payas/git/elpa/admin/elpa-admin.el       \
>          -f elpaa-batch-make-one-package bind-key
> Cloning branch bind-key:
> Preparing worktree (new branch 'externals/bind-key')
> branch 'externals/bind-key' set up to track 'origin/externals/bind-key'.
> HEAD is now at 0be480ea77 Merge pull request #1009 from andreyorst/face-spec-set-third-argument
>
> ======== Building tarball archive-devel/bind-key-2.4.1.0.20221029.145719.tar...
> ######## Built new package archive-devel/bind-key-2.4.1.0.20221029.145719.tar!
> ======== Building tarball archive/bind-key-2.4.1.tar...
> ######## Built new package archive/bind-key-2.4.1.tar!
>
> ~/g/elpa main ?1 1.2s ? make packages/bind-key
> emacs --batch -Q -l admin/elpa-admin.el \
>          -f elpaa-batch-pkg-spec-make-dependencies .pkg-descs.mk
> Generating description file packages/bind-key/bind-key-pkg.el
> emacs --batch -l admin/elpa-admin.el                               \
>          -f elpaa-batch-generate-autoloads packages/bind-key/bind-key-autoloads.el
>   INFO     Scraping files for loaddefs...
>   INFO     Scraping files for loaddefs...done
>   GEN      bind-key-autoloads.el
> Byte compiling packages/bind-key/bind-chord.el
> Byte compiling packages/bind-key/bind-key.el
> Byte compiling packages/bind-key/doc/setup-ox-hugo.el
>
> In toplevel form:
> packages/bind-key/doc/setup-ox-hugo.el:1:3: Warning: reference to free variable `-*-'
> packages/bind-key/doc/setup-ox-hugo.el:1:7: Warning: reference to free variable `lexical-binding:'
> packages/bind-key/doc/setup-ox-hugo.el:169:51: Warning: reference to free variable `ox-hugo-default-lisp-directory'
> packages/bind-key/doc/setup-ox-hugo.el:192:21: Warning: reference to free variable `org-emphasis-regexp-components'
> packages/bind-key/doc/setup-ox-hugo.el:199:33: Warning: Unused lexical argument `file'
> packages/bind-key/doc/setup-ox-hugo.el:201:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
> packages/bind-key/doc/setup-ox-hugo.el:201:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
> packages/bind-key/doc/setup-ox-hugo.el:207:56: Warning: Unused lexical argument `body'
> packages/bind-key/doc/setup-ox-hugo.el:215:11: Warning: assignment to free variable `org-confirm-babel-evaluate'
> packages/bind-key/doc/setup-ox-hugo.el:218:11: Warning: assignment to free variable `org-export-headline-levels'
> packages/bind-key/doc/setup-ox-hugo.el:219:19: Warning: reference to free variable `org-export-exclude-tags'
> packages/bind-key/doc/setup-ox-hugo.el:219:19: Warning: assignment to free variable `org-export-exclude-tags'
>
> In end of data:
> packages/bind-key/doc/setup-ox-hugo.el:215:40: Warning: the function `ox-hugo-org-confirm-babel-evaluate-fn' is not known to be defined.
> packages/bind-key/doc/setup-ox-hugo.el:195:4: Warning: the function `org-set-emph-re' is not known to be defined.
> packages/bind-key/doc/setup-ox-hugo.el:185:4: Warning: the function `org-hugo-export-wim-to-md' is not known to be defined.
> packages/bind-key/doc/setup-ox-hugo.el:52:49: Warning: the function `vc-git-root' is not known to be defined.
> make: *** [GNUmakefile:119: packages/bind-key/doc/setup-ox-hugo.elc] Error 1
> ~/g/elpa main ?1 3.5s [2] make packages/use-package
>
> Byte compiling packages/use-package/doc/setup-ox-hugo.el
>
> In toplevel form:
> packages/use-package/doc/setup-ox-hugo.el:192:51: Warning: reference to free variable `ox-hugo-default-lisp-directory'
> packages/use-package/doc/setup-ox-hugo.el:215:21: Warning: reference to free variable `org-emphasis-regexp-components'
> packages/use-package/doc/setup-ox-hugo.el:222:33: Warning: Unused lexical argument `file'
> packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
> packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
> packages/use-package/doc/setup-ox-hugo.el:230:56: Warning: Unused lexical argument `body'
> packages/use-package/doc/setup-ox-hugo.el:238:11: Warning: assignment to free variable `org-confirm-babel-evaluate'
> packages/use-package/doc/setup-ox-hugo.el:241:11: Warning: assignment to free variable `org-export-headline-levels'
> packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: reference to free variable `org-export-exclude-tags'
> packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: assignment to free variable `org-export-exclude-tags'
>
> In end of data:
> packages/use-package/doc/setup-ox-hugo.el:238:40: Warning: the function `ox-hugo-org-confirm-babel-evaluate-fn' is not known to be defined.
> packages/use-package/doc/setup-ox-hugo.el:218:4: Warning: the function `org-set-emph-re' is not known to be defined.
> packages/use-package/doc/setup-ox-hugo.el:208:4: Warning: the function `org-hugo-export-wim-to-md' is not known to be defined.
> packages/use-package/doc/setup-ox-hugo.el:75:49: Warning: the function `vc-git-root' is not known to be defined.
> make: *** [GNUmakefile:119: packages/use-package/doc/setup-ox-hugo.elc] Error 1

I will once more argue that it might be easier to remove these files
from the repository entirely.

Re: [ELPA] New package: use-package

[Payas Relekar]

Philip Kaludercic <philipk@posteo.net> writes:

> Payas Relekar <relekarpayas@gmail.com> writes:
>
>> My understanding is that we only need to add copyrights to the file
>> because entire repo is cloned to GNU machines. But even after adding
>> copyright headers, IMO adding doc/* to :ignored-files is the right thing
>> to do as it does not serve users directly.
>
> I can imagine that replacing "doc/*" with "doc/" might help, as
> `elpaa--copyright-files' doesn't appear to do any globing, instead just
> tries to find the file using `member' (ie. using a string comparison
> and not even `file-equal-p').

Do you mean in .elpaignore? Because doc/ is not added to :ignored-files
right now.

>> ======== Building tarball archive-devel/use-package-2.4.4.0.20221103.163652.tar...
>> Build error for archive-devel/use-package-2.4.4.0.20221103.163652.tar: (error "Error-indicating exit code in elpaa--call-sandboxed:
>> bwrap: execvp makeinfo: No such file or directory
>> ")
>
> This is suspicious, where is makeinfo located?  Perhaps you can find out
> more if you set the environmental variable "ELPA_DEBUG"?

I did not set this variable. What should its value be?

>> In toplevel form:
>> packages/use-package/doc/setup-ox-hugo.el:192:51: Warning: reference to free variable `ox-hugo-default-lisp-directory'
>> packages/use-package/doc/setup-ox-hugo.el:215:21: Warning: reference to free variable `org-emphasis-regexp-components'
>> packages/use-package/doc/setup-ox-hugo.el:222:33: Warning: Unused lexical argument `file'
>> packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
>> packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
>> packages/use-package/doc/setup-ox-hugo.el:230:56: Warning: Unused lexical argument `body'
>> packages/use-package/doc/setup-ox-hugo.el:238:11: Warning: assignment to free variable `org-confirm-babel-evaluate'
>> packages/use-package/doc/setup-ox-hugo.el:241:11: Warning: assignment to free variable `org-export-headline-levels'
>> packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: reference to free variable `org-export-exclude-tags'
>> packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: assignment to free variable `org-export-exclude-tags'
>>
>> In end of data:
>> packages/use-package/doc/setup-ox-hugo.el:238:40: Warning: the function `ox-hugo-org-confirm-babel-evaluate-fn' is not known to be defined.
>> packages/use-package/doc/setup-ox-hugo.el:218:4: Warning: the function `org-set-emph-re' is not known to be defined.
>> packages/use-package/doc/setup-ox-hugo.el:208:4: Warning: the function `org-hugo-export-wim-to-md' is not known to be defined.
>> packages/use-package/doc/setup-ox-hugo.el:75:49: Warning: the function `vc-git-root' is not known to be defined.
>> make: *** [GNUmakefile:119: packages/use-package/doc/setup-ox-hugo.elc] Error 1
>
> The ignored files are just not included into the tarball (see
> `elpaa--make-one-tarball-1' in elpa-admin.el), but they are still byte
> compiled AFAIK.

That feels like waste of CPU cycles.

> I will once more argue that it might be easier to remove these files
> from the repository entirely.

As much as I agree, that would be John's call. He does maintain separate
webpage for use-package keywords, but I'll say Github already renders
README well enough (and also uses ox-hugo under the hood IIRC).

John, WDYT?

--

Re: [ELPA] New package: use-package

[Philip Kaludercic]

Payas Relekar <relekarpayas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Payas Relekar <relekarpayas@gmail.com> writes:
>>
>>> My understanding is that we only need to add copyrights to the file
>>> because entire repo is cloned to GNU machines. But even after adding
>>> copyright headers, IMO adding doc/* to :ignored-files is the right thing
>>> to do as it does not serve users directly.
>>
>> I can imagine that replacing "doc/*" with "doc/" might help, as
>> `elpaa--copyright-files' doesn't appear to do any globing, instead just
>> tries to find the file using `member' (ie. using a string comparison
>> and not even `file-equal-p').
>
> Do you mean in .elpaignore? Because doc/ is not added to :ignored-files
> right now.

Ah, I forgot that.  In that case elpa-admin.el only checks the file when
creating the package, but it isn't used to exclude files from the
copyright check.  I don't know if there is a reason for this.

>>> ======== Building tarball archive-devel/use-package-2.4.4.0.20221103.163652.tar...
>>> Build error for archive-devel/use-package-2.4.4.0.20221103.163652.tar: (error "Error-indicating exit code in elpaa--call-sandboxed:
>>> bwrap: execvp makeinfo: No such file or directory
>>> ")
>>
>> This is suspicious, where is makeinfo located?  Perhaps you can find out
>> more if you set the environmental variable "ELPA_DEBUG"?
>
> I did not set this variable. What should its value be?

Any non-empty value.  Feel free to take a peek into elpa-admin.el,
you'll find the following line in there:

       (getenv "ELPA_DEBUG")

The documentation says "Value is nil if VARIABLE is undefined in the
environment.  Otherwise, value is a string.".

>>> In toplevel form:
>>> packages/use-package/doc/setup-ox-hugo.el:192:51: Warning: reference to free variable `ox-hugo-default-lisp-directory'
>>> packages/use-package/doc/setup-ox-hugo.el:215:21: Warning: reference to free variable `org-emphasis-regexp-components'
>>> packages/use-package/doc/setup-ox-hugo.el:222:33: Warning: Unused lexical argument `file'
>>> packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
>>> packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
>>> packages/use-package/doc/setup-ox-hugo.el:230:56: Warning: Unused lexical argument `body'
>>> packages/use-package/doc/setup-ox-hugo.el:238:11: Warning: assignment to free variable `org-confirm-babel-evaluate'
>>> packages/use-package/doc/setup-ox-hugo.el:241:11: Warning: assignment to free variable `org-export-headline-levels'
>>> packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: reference to free variable `org-export-exclude-tags'
>>> packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: assignment to free variable `org-export-exclude-tags'
>>>
>>> In end of data:
>>> packages/use-package/doc/setup-ox-hugo.el:238:40: Warning: the function `ox-hugo-org-confirm-babel-evaluate-fn' is not known to be defined.
>>> packages/use-package/doc/setup-ox-hugo.el:218:4: Warning: the function `org-set-emph-re' is not known to be defined.
>>> packages/use-package/doc/setup-ox-hugo.el:208:4: Warning: the function `org-hugo-export-wim-to-md' is not known to be defined.
>>> packages/use-package/doc/setup-ox-hugo.el:75:49: Warning: the function `vc-git-root' is not known to be defined.
>>> make: *** [GNUmakefile:119: packages/use-package/doc/setup-ox-hugo.elc] Error 1
>>
>> The ignored files are just not included into the tarball (see
>> `elpaa--make-one-tarball-1' in elpa-admin.el), but they are still byte
>> compiled AFAIK.
>
> That feels like waste of CPU cycles.

Probably...

>> I will once more argue that it might be easier to remove these files
>> from the repository entirely.
>
> As much as I agree, that would be John's call. 

John, what do you say?  With use-package added to ELPA, the
documentation would automatically be made available on elpa.gnu.org, so
there might not be a need for a special website.

>                                                He does maintain separate
> webpage for use-package keywords, but I'll say Github already renders
> README well enough (and also uses ox-hugo under the hood IIRC).

GitHub uses ox-hugo?  That would be news to me.  Either way, I believe
that now that a texinfo manual has been written (right?), the
requirements have changed.

> John, WDYT?
>
> --

Re: [ELPA] New package: use-package

[John Wiegley]

>>>>> Philip Kaludercic <philipk@posteo.net> writes:

> John, what do you say? With use-package added to ELPA, the documentation
> would automatically be made available on elpa.gnu.org, so there might not be
> a need for a special website.

That's quite fine with me!

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] New package: use-package

[Philip Kaludercic]

John Wiegley <johnw@gnu.org> writes:

>>>>>> Philip Kaludercic <philipk@posteo.net> writes:
>
>> John, what do you say? With use-package added to ELPA, the documentation
>> would automatically be made available on elpa.gnu.org, so there might not be
>> a need for a special website.
>
> That's quite fine with me!

Payas, will you take care of that?

Re: [ELPA] New package: use-package

[Payas Relekar]

Philip Kaludercic <philipk@posteo.net> writes:

> John Wiegley <johnw@gnu.org> writes:
>
>>>>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> John, what do you say? With use-package added to ELPA, the documentation
>>> would automatically be made available on elpa.gnu.org, so there might not be
>>> a need for a special website.
>>
>> That's quite fine with me!
>
> Payas, will you take care of that?

Thanks for confirmation John!

I created another PR to remove doc/ and bump version.

The build seems to complete without any errors on my local for bind-key.
Still haven't figured out why bubblewrap cannot find texinfo. Probably
something to do with how NixOS builds stuff.

Anyway, I hope this will be the last set of changes on road to ELPA.
--

Re: [ELPA] New package: use-package

[Philip Kaludercic]

Payas Relekar <relekarpayas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> John Wiegley <johnw@gnu.org> writes:
>>
>>>>>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> John, what do you say? With use-package added to ELPA, the documentation
>>>> would automatically be made available on elpa.gnu.org, so there might not be
>>>> a need for a special website.
>>>
>>> That's quite fine with me!
>>
>> Payas, will you take care of that?
>
> Thanks for confirmation John!
>
> I created another PR to remove doc/ and bump version.
>
> The build seems to complete without any errors on my local for bind-key.
> Still haven't figured out why bubblewrap cannot find texinfo. Probably
> something to do with how NixOS builds stuff.
>
> Anyway, I hope this will be the last set of changes on road to ELPA.

Before this is done, I have a few comments on the current manual.  In
the section "Installing from an Elpa Archive", goes into how to
configure MELPA/MELPA-Stable.  Is this still necessary?  It might also
be a good idea to replace ".emacs" with "init.el", as this is the
preferred configuration file AFAIK.  I don't know how important this is,
but there are minor typographical issues such as the inconsistent type
setting of "use-package" (sometimes with @code, sometimes without), the
overuse of @code when @var, @key or @kbd would be better or writing "see
@ref" instead of using @xref/@pxref.

Also, it appears I was mistaken in assuming the manual was finished.
There are still large holes:

--8<---------------cut here---------------start------------->8---
@node Getting Started
@chapter Getting Started

TODO@. For now, see @code{README.md}.
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
@node Debugging Tools
@chapter Debugging Tools

TODO
--8<---------------cut here---------------end--------------->8---

Re: [ELPA] New package: use-package

[Payas Relekar]

Philip Kaludercic <philipk@posteo.net> writes:

> Before this is done, I have a few comments on the current manual.  In
> the section "Installing from an Elpa Archive", goes into how to
> configure MELPA/MELPA-Stable.  Is this still necessary?  It might also
> be a good idea to replace ".emacs" with "init.el", as this is the
> preferred configuration file AFAIK.  I don't know how important this is,
> but there are minor typographical issues such as the inconsistent type
> setting of "use-package" (sometimes with @code, sometimes without), the
> overuse of @code when @var, @key or @kbd would be better or writing "see
> @ref" instead of using @xref/@pxref.

Installation instructions should indeed point to GNU ELPA, and I will get to
fixing that by end of today. I converted the PR to draft to signal it is
incomplete for now.

> Also, it appears I was mistaken in assuming the manual was finished.
> There are still large holes:
>
> @node Getting Started
> @chapter Getting Started
>
> TODO@. For now, see @code{README.md}.
>
> @node Debugging Tools
> @chapter Debugging Tools
>
> TODO

Philip, since we are targeting just ELPA, do you think this can be
worked on after publishing? Merging to mainline is a distant issue, and
fixing manual is a future step on that path, as listed before:

> 1. Get use-package in ELPA
> 2. Complete all documentation
> 3. Prepare documentation in texinfo
>    Will cross that bridge when 2 is done.
> 4. Add all relevant files to emacs.git
>    TBD when 3 is done.
> 5. Ensure everything loads properly

--

Re: [ELPA] New package: use-package

[Philip Kaludercic]

Payas Relekar <relekarpayas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Before this is done, I have a few comments on the current manual.  In
>> the section "Installing from an Elpa Archive", goes into how to
>> configure MELPA/MELPA-Stable.  Is this still necessary?  It might also
>> be a good idea to replace ".emacs" with "init.el", as this is the
>> preferred configuration file AFAIK.  I don't know how important this is,
>> but there are minor typographical issues such as the inconsistent type
>> setting of "use-package" (sometimes with @code, sometimes without), the
>> overuse of @code when @var, @key or @kbd would be better or writing "see
>> @ref" instead of using @xref/@pxref.
>
> Installation instructions should indeed point to GNU ELPA, and I will get to
> fixing that by end of today. I converted the PR to draft to signal it is
> incomplete for now.

Ok.

>> Also, it appears I was mistaken in assuming the manual was finished.
>> There are still large holes:
>>
>> @node Getting Started
>> @chapter Getting Started
>>
>> TODO@. For now, see @code{README.md}.
>>
>> @node Debugging Tools
>> @chapter Debugging Tools
>>
>> TODO
>
> Philip, since we are targeting just ELPA, do you think this can be
> worked on after publishing? Merging to mainline is a distant issue, and
> fixing manual is a future step on that path, as listed before:

Sure, I am not blocking anything, I just wasn't sure if this was a
mistake or not.  If this is the plan, feel free to proceed.  My only
real concern is that I had mistakenly said the documentation on
elpa.gnu.org would be able to replace the contents of the doc/
directory, which isn't the case right now.

>> 1. Get use-package in ELPA
>> 2. Complete all documentation
>> 3. Prepare documentation in texinfo
>>    Will cross that bridge when 2 is done.

While we are at it, is there a rationale for this order?  I mean, there
is no hurry, right? My misunderstanding was that the order was 2 -> 3 ->
1.  Or are you planning to have use-package ready for Emacs 29?

>> 4. Add all relevant files to emacs.git
>>    TBD when 3 is done.
>> 5. Ensure everything loads properly



> --

Re: [ELPA] New package: use-package

[Payas Relekar]

Philip Kaludercic <philipk@posteo.net> writes:

>>> 1. Get use-package in ELPA
>>> 2. Complete all documentation
>>> 3. Prepare documentation in texinfo
>>>    Will cross that bridge when 2 is done.
>
> While we are at it, is there a rationale for this order?  I mean, there
> is no hurry, right? My misunderstanding was that the order was 2 -> 3 ->
> 1.  Or are you planning to have use-package ready for Emacs 29?

If you mean merging use-package into emacs.git, that will definitely not
be happening (at least if I'm the only one working on it).

As for the order rationale, getting use-package to ELPA means less
friction and more users can try it out, more feedback, more eyeballs,
basically.

Ultimate aim here is to make use-package to emacs.git, so users have
use-package available without any effort. ELPA is just a step in that
direction.

1 -> 2 -> 3 is also how Eglot went about and it worked quite well for it.

From my understanding, ELPA has less stringent requirements for
documentation and testing compared to core. Since I cannot commit enough
time to complete all the tasks before expected 29 branch-off, ELPA is a
good compromise IMO.

--

Re: [ELPA] New package: use-package

[Philip Kaludercic]

Payas Relekar <relekarpayas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>>> 1. Get use-package in ELPA
>>>> 2. Complete all documentation
>>>> 3. Prepare documentation in texinfo
>>>>    Will cross that bridge when 2 is done.
>>
>> While we are at it, is there a rationale for this order?  I mean, there
>> is no hurry, right? My misunderstanding was that the order was 2 -> 3 ->
>> 1.  Or are you planning to have use-package ready for Emacs 29?
>
> If you mean merging use-package into emacs.git, that will definitely not
> be happening (at least if I'm the only one working on it).

Ok.

> As for the order rationale, getting use-package to ELPA means less
> friction and more users can try it out, more feedback, more eyeballs,
> basically.

What are we trying to find?  From what I know use-package is already a
very mature package, written by very capable people.  I expect most of
the changes to be made after use-package.el has been added to the core.

> Ultimate aim here is to make use-package to emacs.git, so users have
> use-package available without any effort. ELPA is just a step in that
> direction.
>
> 1 -> 2 -> 3 is also how Eglot went about and it worked quite well for it.

Yes, but the arrow between points 2 and 3 would have to be pretty long.
Eglot was an ELPA package from the very beginning, and I don't know if
the documentation was ever as incomplete as it is for use-package right
now.  The rewrite into Texinfo (which is probably what I had confused)
took place just before the package was merged into the core.
use-package will now be added to GNU ELPA with _incomplete_ Texinfo
documentation.  This is my objection.  An outdated manual with "TODO"s
can be more frustrating than no documentation at all.

> From my understanding, ELPA has less stringent requirements for
> documentation and testing compared to core. Since I cannot commit enough
> time to complete all the tasks before expected 29 branch-off, ELPA is a
> good compromise IMO.

Most packages on ELPA don't have any special documentation, most don't
need any documentation either.  Use-package is more complicated, 

Re: [ELPA] New package: use-package

[Payas Relekar]

Philip Kaludercic <philipk@posteo.net> writes:

> What are we trying to find?  From what I know use-package is already a
> very mature package, written by very capable people.  I expect most of
> the changes to be made after use-package.el has been added to the core.
>
>> Ultimate aim here is to make use-package to emacs.git, so users have
>> use-package available without any effort. ELPA is just a step in that
>> direction.
>>
>> 1 -> 2 -> 3 is also how Eglot went about and it worked quite well for it.
>
> Yes, but the arrow between points 2 and 3 would have to be pretty long.
> Eglot was an ELPA package from the very beginning, and I don't know if
> the documentation was ever as incomplete as it is for use-package right
> now.  The rewrite into Texinfo (which is probably what I had confused)
> took place just before the package was merged into the core.
> use-package will now be added to GNU ELPA with _incomplete_ Texinfo
> documentation.  This is my objection.  An outdated manual with "TODO"s
> can be more frustrating than no documentation at all.
>
>> From my understanding, ELPA has less stringent requirements for
>> documentation and testing compared to core. Since I cannot commit enough
>> time to complete all the tasks before expected 29 branch-off, ELPA is a
>> good compromise IMO.
>
> Most packages on ELPA don't have any special documentation, most don't
> need any documentation either.  Use-package is more complicated,

All fair points. I will focus on getting TexInfo doc in shape before
making PR ready for review. Should we comment out use-package recipe in
elpa-packages.el until then?

--

Re: [ELPA] New package: use-package

[Philip Kaludercic]

Payas Relekar <relekarpayas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> What are we trying to find?  From what I know use-package is already a
>> very mature package, written by very capable people.  I expect most of
>> the changes to be made after use-package.el has been added to the core.
>>
>>> Ultimate aim here is to make use-package to emacs.git, so users have
>>> use-package available without any effort. ELPA is just a step in that
>>> direction.
>>>
>>> 1 -> 2 -> 3 is also how Eglot went about and it worked quite well for it.
>>
>> Yes, but the arrow between points 2 and 3 would have to be pretty long.
>> Eglot was an ELPA package from the very beginning, and I don't know if
>> the documentation was ever as incomplete as it is for use-package right
>> now.  The rewrite into Texinfo (which is probably what I had confused)
>> took place just before the package was merged into the core.
>> use-package will now be added to GNU ELPA with _incomplete_ Texinfo
>> documentation.  This is my objection.  An outdated manual with "TODO"s
>> can be more frustrating than no documentation at all.
>>
>>> From my understanding, ELPA has less stringent requirements for
>>> documentation and testing compared to core. Since I cannot commit enough
>>> time to complete all the tasks before expected 29 branch-off, ELPA is a
>>> good compromise IMO.
>>
>> Most packages on ELPA don't have any special documentation, most don't
>> need any documentation either.  Use-package is more complicated,
>
> All fair points. I will focus on getting TexInfo doc in shape before
> making PR ready for review. Should we comment out use-package recipe in
> elpa-packages.el until then?

As long as the version tag is not bumped, there shouldn't be a release.
So I don't think there is a need for change anything.

Adding use-package to core

[Stefan Kangas]

Payas Relekar <relekarpayas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>>> 1. Get use-package in ELPA
>>>> 2. Complete all documentation
>>>> 3. Prepare documentation in texinfo
>>>>    Will cross that bridge when 2 is done.
>>
>> While we are at it, is there a rationale for this order?  I mean, there
>> is no hurry, right? My misunderstanding was that the order was 2 -> 3 ->
>> 1.  Or are you planning to have use-package ready for Emacs 29?
>
> If you mean merging use-package into emacs.git, that will definitely not
> be happening (at least if I'm the only one working on it).
[...]
> From my understanding, ELPA has less stringent requirements for
> documentation and testing compared to core. Since I cannot commit enough
> time to complete all the tasks before expected 29 branch-off, ELPA is a
> good compromise IMO.

OK, I'll bite.  I have time to dedicate to this task; perhaps we can
move quickly enough for Emacs 29.  Ultimately, the decision will be with
the maintainers, but it seems to me that use-package.el itself is in
shape for inclusion.

Could you write up a summary of what needs doing before we can add
use-package to emacs.git?  Is it just a matter of writing up some more
documentation, or is there more that needs doing?

> As for the order rationale, getting use-package to ELPA means less
> friction and more users can try it out, more feedback, more eyeballs,
> basically.

If we get it into core, we can make it into a :core package.

Re: Adding use-package to core

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 3430 bytes --]

Stefan Kangas <stefankangas@gmail.com> writes:

> Payas Relekar <relekarpayas@gmail.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>>>> 1. Get use-package in ELPA
>>>>> 2. Complete all documentation
>>>>> 3. Prepare documentation in texinfo
>>>>>    Will cross that bridge when 2 is done.
>>>
>>> While we are at it, is there a rationale for this order?  I mean, there
>>> is no hurry, right? My misunderstanding was that the order was 2 -> 3 ->
>>> 1.  Or are you planning to have use-package ready for Emacs 29?
>>
>> If you mean merging use-package into emacs.git, that will definitely not
>> be happening (at least if I'm the only one working on it).
> [...]
>> From my understanding, ELPA has less stringent requirements for
>> documentation and testing compared to core. Since I cannot commit enough
>> time to complete all the tasks before expected 29 branch-off, ELPA is a
>> good compromise IMO.
>
> OK, I'll bite.  I have time to dedicate to this task; perhaps we can
> move quickly enough for Emacs 29.  Ultimately, the decision will be with
> the maintainers, but it seems to me that use-package.el itself is in
> shape for inclusion.

That would certainly be great1

> Could you write up a summary of what needs doing before we can add
> use-package to emacs.git?  Is it just a matter of writing up some more
> documentation, or is there more that needs doing?

Payas and I can up with the following list

  1. Get use-package in ELPA
  2. Complete all documentation
  3. Prepare documentation in texinfo
     Will cross that bridge when 2 is done.
  4. Add all relevant files to emacs.git
     TBD when 3 is done.
  5. Ensure everything loads properly

The first point has been done, but hasn't been finalised.  The most
tricky part IMO right now is to complete the .texi documentation.  Take
a look at

https://raw.githubusercontent.com/jwiegley/use-package/master/use-package.texi

I have previously commented on what has do be done here
(<87o7v37sqh.fsf@posteo.net>, <871qqhby2k.fsf@posteo.net>):

    Take a look at use-package.texi in the use-package repository.  There
    are currently two TODO that ought to be addressed.  And as the file is
    generated, the texinfo markup is probably not as idiomatic as it ought
    to be.  There are at least a few instances where @code is used instead
    of @kbd, @key or @var.  @ref where @xref/@pxref might be better.  Content-wise
    a few sections such as how to install the package will be outdated, and
    I'd rephrase the sections that mention MELPA to use ELPA examples.  I
    also notice that the spacing is inconsistent, and one should try to keep
    ensure that each full stop is followed by two spaces.

My worry here are the TODO sections -- they either have to be removed or
expanded:

--8<---------------cut here---------------start------------->8---
@node Getting Started
@chapter Getting Started

TODO@. For now, see @code{README.md}.
--8<---------------cut here---------------end--------------->8---

If the manual is pointing to the README, we might just have to convert
the Markdown document to Texi and clean it up.  My hunch is that the
README isn't written like a good manual, so it won't be that easy.

... On the other hand, if this TODO really just wants the "Getting
Started" section from the README, this should be trivial.  All one would
need is to clean up the following that I quickly converted using Pandoc:


[-- Attachment #2: Type: text/plain, Size: 1918 bytes --]

Here is the simplest @code{use-package} declaration:

@verbatim
;; This is only needed once, near the top of the file
(eval-when-compile
  ;; Following line is not needed if use-package.el is in ~/.emacs.d
  (add-to-list 'load-path "<path where use-package is installed>")
  (require 'use-package))

(use-package foo)
@end verbatim

This loads in the package @code{foo}, but only if @code{foo} is
available on your system. If not, a warning is logged to the
@code{*Messages*} buffer.

Use the @code{:init} keyword to execute code before a package is loaded.
It accepts one or more forms, up to the next keyword:

@verbatim
(use-package foo
  :init
  (setq foo-variable t))
@end verbatim

Similarly, @code{:config} can be used to execute code after a package is
loaded. In cases where loading is done lazily (see more about
autoloading below), this execution is deferred until after the autoload
occurs:

@verbatim
(use-package foo
  :init
  (setq foo-variable t)
  :config
  (foo-mode 1))
@end verbatim

As you might expect, you can use @code{:init} and @code{:config}
together:

@verbatim
(use-package color-moccur
  :commands (isearch-moccur isearch-all)
  :bind (("M-s O" . moccur)
         :map isearch-mode-map
         ("M-o" . isearch-moccur)
         ("M-O" . isearch-moccur-all))
  :init
  (setq isearch-lazy-highlight t)
  :config
  (use-package moccur-edit))
@end verbatim

In this case, I want to autoload the commands @code{isearch-moccur} and
@code{isearch-all} from @code{color-moccur.el}, and bind keys both at
the global level and within the @code{isearch-mode-map} (see next
section). When the package is actually loaded (by using one of these
commands), @code{moccur-edit} is also loaded, to allow editing of the
@code{moccur} buffer.

If you autoload no-interactive function, please use @code{:autoload}.

@verbatim
(use-package org-crypt
  :autoload org-crypt-use-before-save-magic)
@end verbatim

[-- Attachment #3: Type: text/plain, Size: 663 bytes --]


--8<---------------cut here---------------start------------->8---
@node Debugging Tools
@chapter Debugging Tools

TODO
--8<---------------cut here---------------end--------------->8---

This is a more technical topic that probably has to be written by
someone who is knowledgeable with the internals and implementation
details of use-package.  Either we find someone like that -- who has
time -- or the chapter is removed for now.

>> As for the order rationale, getting use-package to ELPA means less
>> friction and more users can try it out, more feedback, more eyeballs,
>> basically.
>
> If we get it into core, we can make it into a :core package.

Right.

Re: Adding use-package to core

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> Payas and I can up with the following list
>
>   1. Get use-package in ELPA
>   2. Complete all documentation
>   3. Prepare documentation in texinfo
>      Will cross that bridge when 2 is done.
>   4. Add all relevant files to emacs.git
>      TBD when 3 is done.
>   5. Ensure everything loads properly
>
> The first point has been done, but hasn't been finalised.

I didn't follow the discussion, but it seems like adding it to GNU ELPA
is being worked on.  That is good.

But I think one question remains, unless I missed some important part of
the discussion (and please forgive me if I did):

We need to figure out how development will proceed after adding it to
emacs.git.  I see three options:

1. Development will continue as before, in the old repository and forge
   (currently GitHub).  This case is different from Eglot, and AFAIU
   more like cc-mode, org-mode (or previously Gnus):

   - Development mainly takes place externally.
   - When a new version of use-package is released, it is manually
     synched (a.k.a. copied) to emacs.git and committed as basically
     "new version".  [So to read the full git log, one would need to
     clone use-package.git -- we don't preserve it.]
   - Someone needs to be in charge of (presumably manually) synching
     changes in emacs.git back to use-package.git.

2. Development moves to emacs.git wholesale, along the same lines as we
   did with eglot.  This would take more work, and I guess collaboration
   and active interest from John.

3. We wait until we can include GNU ELPA packages in the Emacs
   distribution.  AFAIK, this is not actively worked on, and would in
   practice mean that we just wait until someone steps up to volunteer
   for that (i.e. we effectively do nothing, for now).

On balance, the first option (1) seems to me the best one here, as
use-package development is already quite established externally and it
seems smart to leverage that existing community to our advantage.  The
main advantage we are looking for here is to ship use-package with
Emacs, and we already get that with option 1.

Perhaps, in this case, it also doesn't make sense to make use-package
into a :core package.  We would then just need to worry about synching
the latest version of use-package to emacs.git before releasing a new
version of Emacs.  We would not have to update it all the time just to
get it released on GNU ELPA.

I've CC:ed John in case he has anything to add.

>     Take a look at use-package.texi in the use-package repository.  There
>     are currently two TODO that ought to be addressed.  And as the file is
>     generated, the texinfo markup is probably not as idiomatic as it ought
>     to be.  There are at least a few instances where @code is used instead
>     of @kbd, @key or @var.  @ref where @xref/@pxref might be better.  Content-wise
>     a few sections such as how to install the package will be outdated, and
>     I'd rephrase the sections that mention MELPA to use ELPA examples.  I
>     also notice that the spacing is inconsistent, and one should try to keep
>     ensure that each full stop is followed by two spaces.

Agreed.

> My worry here are the TODO sections -- they either have to be removed or
> expanded:
>
> --8<---------------cut here---------------start------------->8---
> @node Getting Started
> @chapter Getting Started
>
> TODO@. For now, see @code{README.md}.
> --8<---------------cut here---------------end--------------->8---
>
> If the manual is pointing to the README, we might just have to convert
> the Markdown document to Texi and clean it up.  My hunch is that the
> README isn't written like a good manual, so it won't be that easy.
>
> ... On the other hand, if this TODO really just wants the "Getting
> Started" section from the README, this should be trivial.  All one would
> need is to clean up the following that I quickly converted using Pandoc:

I think we should be able to just use the section "Getting started" from
README.md.  I think we can just comment out the sections
"Issues/Requests" and "Debugging Tools" until they are actually written.

However, the documentation seems to be currently written in Org-mode,
from where it is exported using Hugo[1] to a website:

    https://jwiegley.github.io/use-package/getting-started/

If it is important to continue doing that, I think we should work with
the org-mode sources rather than the texinfo ones.  It would be useful
if John could let us know if he has any preferences in this regard.

As for the formatting issues in the org->texinfo conversion, I believe
that Org-mode has largely solved them.  With some luck, it should be a
small matter of imitating what they did.  In any case, it should be
possible to find solutions and/or workarounds.

So all in all, the documentation will take some work, but nothing too
crazy.

The harder job going forward will be keeping use-package.{org,texi}
up-to-date with README.md, if that will continue to be an important
source of documentation.  Perhaps README.md should be restricted in
scope to make that job easier.

Footnotes:
[1]  https://gohugo.io/

Re: Adding use-package to core

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Payas and I can up with the following list
>>
>>   1. Get use-package in ELPA
>>   2. Complete all documentation
>>   3. Prepare documentation in texinfo
>>      Will cross that bridge when 2 is done.
>>   4. Add all relevant files to emacs.git
>>      TBD when 3 is done.
>>   5. Ensure everything loads properly
>>
>> The first point has been done, but hasn't been finalised.
>
> I didn't follow the discussion, but it seems like adding it to GNU ELPA
> is being worked on.  That is good.

Actually it is done, but I advised Payas to postpone it until the
documentation is ready, which makes the package more useful.  Even if
use-package isn't added in time for 29, working on the issue would still
be useful for the ELPA initiative.

> But I think one question remains, unless I missed some important part of
> the discussion (and please forgive me if I did):

(None of this was discussed, to my recollection)

> We need to figure out how development will proceed after adding it to
> emacs.git.  I see three options:
>
> 1. Development will continue as before, in the old repository and forge
>    (currently GitHub).  This case is different from Eglot, and AFAIU
>    more like cc-mode, org-mode (or previously Gnus):
>
>    - Development mainly takes place externally.
>    - When a new version of use-package is released, it is manually
>      synched (a.k.a. copied) to emacs.git and committed as basically
>      "new version".  [So to read the full git log, one would need to
>      clone use-package.git -- we don't preserve it.]
>    - Someone needs to be in charge of (presumably manually) synching
>      changes in emacs.git back to use-package.git.
>
> 2. Development moves to emacs.git wholesale, along the same lines as we
>    did with eglot.  This would take more work, and I guess collaboration
>    and active interest from John.
>
> 3. We wait until we can include GNU ELPA packages in the Emacs
>    distribution.  AFAIK, this is not actively worked on, and would in
>    practice mean that we just wait until someone steps up to volunteer
>    for that (i.e. we effectively do nothing, for now).
>
> On balance, the first option (1) seems to me the best one here, as
> use-package development is already quite established externally and it
> seems smart to leverage that existing community to our advantage.  The
> main advantage we are looking for here is to ship use-package with
> Emacs, and we already get that with option 1.

FWIW I agree, and think this has worked well enough for a number of
larger packages (another example are the Modus Themes).  It is sad that
the revision history is broken, but that is a limitation of Git IMO.

> Perhaps, in this case, it also doesn't make sense to make use-package
> into a :core package.  We would then just need to worry about synching
> the latest version of use-package to emacs.git before releasing a new
> version of Emacs.  We would not have to update it all the time just to
> get it released on GNU ELPA.

I cannot evaluate this, but isn't use-package a relatively stable
package, that is mostly being bug-fixed?  There really aren't that many
new features being added all the time, so this might not be that
important.  Or am I mistaken?

> I've CC:ed John in case he has anything to add.
>
>>     Take a look at use-package.texi in the use-package repository.  There
>>     are currently two TODO that ought to be addressed.  And as the file is
>>     generated, the texinfo markup is probably not as idiomatic as it ought
>>     to be.  There are at least a few instances where @code is used instead
>>     of @kbd, @key or @var.  @ref where @xref/@pxref might be better.  Content-wise
>>     a few sections such as how to install the package will be outdated, and
>>     I'd rephrase the sections that mention MELPA to use ELPA examples.  I
>>     also notice that the spacing is inconsistent, and one should try to keep
>>     ensure that each full stop is followed by two spaces.
>
> Agreed.
>
>> My worry here are the TODO sections -- they either have to be removed or
>> expanded:
>>
>> --8<---------------cut here---------------start------------->8---
>> @node Getting Started
>> @chapter Getting Started
>>
>> TODO@. For now, see @code{README.md}.
>> --8<---------------cut here---------------end--------------->8---
>>
>> If the manual is pointing to the README, we might just have to convert
>> the Markdown document to Texi and clean it up.  My hunch is that the
>> README isn't written like a good manual, so it won't be that easy.
>>
>> ... On the other hand, if this TODO really just wants the "Getting
>> Started" section from the README, this should be trivial.  All one would
>> need is to clean up the following that I quickly converted using Pandoc:
>
> I think we should be able to just use the section "Getting started" from
> README.md.  I think we can just comment out the sections
> "Issues/Requests" and "Debugging Tools" until they are actually written.

Someone has to make that choice, and I am fine if you are the one who
decides to do so.

> However, the documentation seems to be currently written in Org-mode,
> from where it is exported using Hugo[1] to a website:
>
>     https://jwiegley.github.io/use-package/getting-started/
>
> If it is important to continue doing that, I think we should work with
> the org-mode sources rather than the texinfo ones.  It would be useful
> if John could let us know if he has any preferences in this regard.

No, we have recently decided to scrap that documentation source in
favour of the documentation generated on elpa.gnu.org -- that is if I
understood everything correctly.

> As for the formatting issues in the org->texinfo conversion, I believe
> that Org-mode has largely solved them.  With some luck, it should be a
> small matter of imitating what they did.  In any case, it should be
> possible to find solutions and/or workarounds.

Really?  How does Org-mode distinguish between @key, @kbd, @code and
@var?

> So all in all, the documentation will take some work, but nothing too
> crazy.

If you think so, that is great.

> The harder job going forward will be keeping use-package.{org,texi}
> up-to-date with README.md, if that will continue to be an important
> source of documentation.  Perhaps README.md should be restricted in
> scope to make that job easier.

I think this is a good idea in general.  Long READMEs are easy to get
lost in.  If a file asks you to read it, then it should at the very
least be kind enough to keep it short and only focus on pointing you to
the relevant information, that would ideally be found somewhere else.

Re: Adding use-package to core

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> I cannot evaluate this, but isn't use-package a relatively stable
> package, that is mostly being bug-fixed?  There really aren't that many
> new features being added all the time, so this might not be that
> important.  Or am I mistaken?

I don't think you're wrong, however I don't see any clear benefits to
making it a :core package as compared to just adding it as a normal
package, as long as it's developed externally.  It's less work, and
seems to be good enough for org-mode, for example.

But you're right that it might not be that important.  Either or works.

> No, we have recently decided to scrap that documentation source in
> favour of the documentation generated on elpa.gnu.org -- that is if I
> understood everything correctly.

OK, thanks.  I now did my homework and read the related threads (sorry
for not doing that first).

1. Does that mean that it is actually preferred to make all changes
   directly in use-package.texi now?

2. Should use-package.org just be scrapped, then?  (I guess that, if the
   answer is yes, we should first export the latest version of that file
   to use-package.texi, and then continue from there.)

3. Payas mentioned working on the texinfo sources.  What's the status of
   that work?  I'm ready to get started, but it seems better if we can
   avoid doing the same work twice, so maybe I should base it on his
   latest version?

> How does Org-mode distinguish between @key, @kbd, @code and @var?

See org-setup.org, org.org and the generated file org.texi.  Basically
they use org-mode macros to add texinfo markup.

Re: Adding use-package to core

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I cannot evaluate this, but isn't use-package a relatively stable
>> package, that is mostly being bug-fixed?  There really aren't that many
>> new features being added all the time, so this might not be that
>> important.  Or am I mistaken?
>
> I don't think you're wrong, however I don't see any clear benefits to
> making it a :core package as compared to just adding it as a normal
> package, as long as it's developed externally.  It's less work, and
> seems to be good enough for org-mode, for example.
>
> But you're right that it might not be that important.  Either or works.

I just checked elpa-packages, assuming that the modus-themes were
externally synchronised, but apparently this isn't the case.  Maybe we
could take a look at discussion from when Modus was merged into the core,
to find arguments pro and contra.

>> No, we have recently decided to scrap that documentation source in
>> favour of the documentation generated on elpa.gnu.org -- that is if I
>> understood everything correctly.
>
> OK, thanks.  I now did my homework and read the related threads (sorry
> for not doing that first).

No problem.

> 1. Does that mean that it is actually preferred to make all changes
>    directly in use-package.texi now?

That is my understanding

> 2. Should use-package.org just be scrapped, then?  (I guess that, if the
>    answer is yes, we should first export the latest version of that file
>    to use-package.texi, and then continue from there.)

That would follow.

> 3. Payas mentioned working on the texinfo sources.  What's the status of
>    that work?  I'm ready to get started, but it seems better if we can
>    avoid doing the same work twice, so maybe I should base it on his
>    latest version?

That I cannot say.

>> How does Org-mode distinguish between @key, @kbd, @code and @var?
>
> See org-setup.org, org.org and the generated file org.texi.  Basically
> they use org-mode macros to add texinfo markup.

Oh, that is interesting.  Perhaps this would work too, my experience
with org->texi has been dissatisfactory but limited.

Re: Adding use-package to core

[Payas Relekar]

First, thank you Stefan for stepping up to do the work!

I have been quite swamped with $LIFE and haven't been able to dedicate
sufficient time to use-package upstreaming as much as I would have
liked. That makes your interest all the more welcome!

Philip Kaludercic <philipk@posteo.net> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> OK, thanks.  I now did my homework and read the related threads (sorry
>> for not doing that first).

I might be bit out of loop on today's emails, let me know if I miss
anything below :)

>> 1. Does that mean that it is actually preferred to make all changes
>>    directly in use-package.texi now?
>
> That is my understanding

+1

>> 2. Should use-package.org just be scrapped, then?  (I guess that, if the
>>    answer is yes, we should first export the latest version of that file
>>    to use-package.texi, and then continue from there.)
>
> That would follow.

Pick whichever way you're most comfortable with, as long as the end
result is acceptable by maintainers, shouldn't be a problem.

>> 3. Payas mentioned working on the texinfo sources.  What's the status of
>>    that work?  I'm ready to get started, but it seems better if we can
>>    avoid doing the same work twice, so maybe I should base it on his
>>    latest version?
>
> That I cannot say.

As mentioned above, I have been barely able to give any time to work on
this. Please go ahead with anything you would like to work on.

>>> How does Org-mode distinguish between @key, @kbd, @code and @var?
>>
>> See org-setup.org, org.org and the generated file org.texi.  Basically
>> they use org-mode macros to add texinfo markup.
>
> Oh, that is interesting.  Perhaps this would work too, my experience
> with org->texi has been dissatisfactory but limited.

I would personally like to see the package in core if at all possible,
and John has also expressed interest in that. Personally I'd prefer if
development continues in core after upstreaming, but it is upto John to
decide. I know that Modus-themes and Org both are developed out of tree,
and only merged in when the package version is bumped. Which means
history is lost, but clearly that hasn't been a problem and maintainers
of those packages prefer it.

--

Re: Adding use-package to core

[Philip Kaludercic]

Payas Relekar <relekarpayas@gmail.com> writes:

>>> OK, thanks.  I now did my homework and read the related threads (sorry
>>> for not doing that first).
>
> I might be bit out of loop on today's emails, let me know if I miss
> anything below :)

It doesn't seem like you missed anything critical.  Thank you for
confirming.

Re: Adding use-package to core

[John Wiegley]

>>>>> Payas Relekar <relekarpayas@gmail.com> writes:

> I would personally like to see the package in core if at all possible, and
> John has also expressed interest in that. Personally I'd prefer if
> development continues in core after upstreaming, but it is upto John to
> decide. I know that Modus-themes and Org both are developed out of tree, and
> only merged in when the package version is bumped. Which means history is
> lost, but clearly that hasn't been a problem and maintainers of those
> packages prefer it.

I'm entirely in support of the code and its development moving directly into
core. Whichever best supports the Emacs developers and the needs of the
community, since it is more than likely that future work will be carried out
by others. I'm ready to hand it off in whatever way is desired by the team
here.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Adding use-package to core

[Stefan Kangas]

John Wiegley <johnw@gnu.org> writes:

>>>>>> Payas Relekar <relekarpayas@gmail.com> writes:
>
>> I would personally like to see the package in core if at all possible, and
>> John has also expressed interest in that. Personally I'd prefer if
>> development continues in core after upstreaming, but it is upto John to
>> decide. I know that Modus-themes and Org both are developed out of tree, and
>> only merged in when the package version is bumped. Which means history is
>> lost, but clearly that hasn't been a problem and maintainers of those
>> packages prefer it.
>
> I'm entirely in support of the code and its development moving directly into
> core. Whichever best supports the Emacs developers and the needs of the
> community, since it is more than likely that future work will be carried out
> by others. I'm ready to hand it off in whatever way is desired by the team
> here.

IMHO, for that to make sense, someone capable would have to volunteer to
maintain it on our side.  If we don't have such a volunteer, it makes
more sense to me to keep development external for now.

If we see a need to move development fully into core in the future, we
can always do that, but the reverse is harder.

(If we want to preserve history when making such a move at a later date,
we could just delete our existing copy of the file from emacs.git and
then merge the full git history, just as we did with eglot.el.)

Re: Adding use-package to core

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> John Wiegley <johnw@gnu.org> writes:
>
>>>>>>> Payas Relekar <relekarpayas@gmail.com> writes:
>>
>>> I would personally like to see the package in core if at all possible, and
>>> John has also expressed interest in that. Personally I'd prefer if
>>> development continues in core after upstreaming, but it is upto John to
>>> decide. I know that Modus-themes and Org both are developed out of tree, and
>>> only merged in when the package version is bumped. Which means history is
>>> lost, but clearly that hasn't been a problem and maintainers of those
>>> packages prefer it.
>>
>> I'm entirely in support of the code and its development moving directly into
>> core. Whichever best supports the Emacs developers and the needs of the
>> community, since it is more than likely that future work will be carried out
>> by others. I'm ready to hand it off in whatever way is desired by the team
>> here.
>
> IMHO, for that to make sense, someone capable would have to volunteer to
> maintain it on our side.  If we don't have such a volunteer, it makes
> more sense to me to keep development external for now.
>
> If we see a need to move development fully into core in the future, we
> can always do that, but the reverse is harder.

I agree, a transitory stage where use-package is still maintained
externally sounds like the safer bet for now.

> (If we want to preserve history when making such a move at a later date,
> we could just delete our existing copy of the file from emacs.git and
> then merge the full git history, just as we did with eglot.el.)

In that case, what is left is completing the .texi manual, or am I
mistaken?  After that, I suppose that placing the right files in the
right places in emacs.git will be less that a days work.

Re: Adding use-package to core

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: John Wiegley <johnw@gnu.org>,  Payas Relekar <relekarpayas@gmail.com>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel
>  <emacs-devel@gnu.org>
> Date: Sun, 13 Nov 2022 07:07:47 +0000
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> >> I'm entirely in support of the code and its development moving directly into
> >> core. Whichever best supports the Emacs developers and the needs of the
> >> community, since it is more than likely that future work will be carried out
> >> by others. I'm ready to hand it off in whatever way is desired by the team
> >> here.
> >
> > IMHO, for that to make sense, someone capable would have to volunteer to
> > maintain it on our side.  If we don't have such a volunteer, it makes
> > more sense to me to keep development external for now.
> >
> > If we see a need to move development fully into core in the future, we
> > can always do that, but the reverse is harder.
> 
> I agree, a transitory stage where use-package is still maintained
> externally sounds like the safer bet for now.

I don't share Stefan's fears.  If the only issue with moving
use-package to core is that someone must step forward to take the
responsibility for maintaining it, I think we can move it into core
without fear.  I see no reason for making a dedicated maintainer for
use-package a prerequisite for importing it, given what John says
about its stability.  It's a non-issue.

Re: Adding use-package to core

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> In that case, what is left is completing the .texi manual, or am I
> mistaken?  After that, I suppose that placing the right files in the
> right places in emacs.git will be less that a days work.

I think so, yes.

Re: Adding use-package to core

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> In that case, what is left is completing the .texi manual, or am I
>> mistaken?  After that, I suppose that placing the right files in the
>> right places in emacs.git will be less that a days work.
>
> I think so, yes.

And just to double-check, you'll start working on that?

Re: Adding use-package to core

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> And just to double-check, you'll start working on that?

Yes, I've started working on use-package.texi.

Re: Adding use-package to core

[Philip Kaludercic]

Philip Kaludercic <philipk@posteo.net> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> John Wiegley <johnw@gnu.org> writes:
>>
>>>>>>>> Payas Relekar <relekarpayas@gmail.com> writes:
>>>
>>>> I would personally like to see the package in core if at all possible, and
>>>> John has also expressed interest in that. Personally I'd prefer if
>>>> development continues in core after upstreaming, but it is upto John to
>>>> decide. I know that Modus-themes and Org both are developed out of tree, and
>>>> only merged in when the package version is bumped. Which means history is
>>>> lost, but clearly that hasn't been a problem and maintainers of those
>>>> packages prefer it.
>>>
>>> I'm entirely in support of the code and its development moving directly into
>>> core. Whichever best supports the Emacs developers and the needs of the
>>> community, since it is more than likely that future work will be carried out
>>> by others. I'm ready to hand it off in whatever way is desired by the team
>>> here.
>>
>> IMHO, for that to make sense, someone capable would have to volunteer to
>> maintain it on our side.  If we don't have such a volunteer, it makes
>> more sense to me to keep development external for now.
>>
>> If we see a need to move development fully into core in the future, we
>> can always do that, but the reverse is harder.
>
> I agree, a transitory stage where use-package is still maintained
> externally sounds like the safer bet for now.
>
>> (If we want to preserve history when making such a move at a later date,
>> we could just delete our existing copy of the file from emacs.git and
>> then merge the full git history, just as we did with eglot.el.)
>
> In that case, what is left is completing the .texi manual, or am I
> mistaken?  After that, I suppose that placing the right files in the
> right places in emacs.git will be less that a days work.

One thing I have noticed since use-package has appeared on ELPA, that
could also be tackled in time is that the package description (C-h P) is
very messy.  It starts like this:

--8<---------------cut here---------------start------------->8---
# `use-package`

[![Join the chat at https://gitter.im/use-package/Lobby](https://badges.gitter.im/use-package/Lobby.svg)](https://gitter.im/use-package/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
[![Build Status](https://github.com/jwiegley/use-package/actions/workflows/test.yml/badge.svg)](https://github.com/jwiegley/use-package/actions)
[![MELPA](https://melpa.org/packages/use-package-badge.svg)](https://melpa.org/#/use-package)
[![MELPA Stable](https://stable.melpa.org/packages/use-package-badge.svg)](https://stable.melpa.org/#/use-package)

The `use-package` macro allows you to isolate package configuration in your
`.emacs` file in a way that is both performance-oriented and, well, tidy.  I
created it because I have over 80 packages that I use in Emacs, and things
were getting difficult to manage.  Yet with this utility my total load time is
around 2 seconds, with no loss of functionality!

**NOTE**: `use-package` is **not** a package manager! Although `use-package`
does have the useful capability to interface with package managers (see
[below](#package-installation)), its primary purpose is for the configuration
and loading of packages.

Notes for users upgrading to 2.x are located [at the bottom](#upgrading-to-2x).

- [Installing use-package](#installing-use-package)
- [Getting started](#getting-started)
- [Key-binding](#key-binding)
	+ [Binding to keymaps](#binding-to-keymaps)
	+ [Binding within local keymaps](#binding-within-local-keymaps)
- [Modes and interpreters](#modes-and-interpreters)
- [Magic handlers](#magic-handlers)
- [Hooks](#hooks)
- [Package customization](#package-customization)
  + [Customizing variables](#customizing-variables)
  + [Customizing faces](#customizing-faces)
- [Notes about lazy loading](#notes-about-lazy-loading)
- [Information about package loads](#information-about-package-loads)
--8<---------------cut here---------------end--------------->8---

And is followed by the entire manual (from the README file).  I wonder
if it would be better to set :redeem in the package specification to
ignore, and instead just display the shorter commentary section:

--8<---------------cut here---------------start------------->8---
;; The `use-package' declaration macro allows you to isolate package
;; configuration in your ".emacs" in a way that is performance-oriented and,
;; well, just tidy.  I created it because I have over 80 packages that I use
;; in Emacs, and things were getting difficult to manage.  Yet with this
;; utility my total load time is just under 1 second, with no loss of
;; functionality!
;;
;; Please see README.md from the same repository for documentation.
--8<---------------cut here---------------end--------------->8---

Perhaps just with the reference to the README.md replaced with a
reference to the forthcoming manual.

Re: Adding use-package to core

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> And is followed by the entire manual (from the README file).  I wonder
> if it would be better to set :redeem in the package specification to
> ignore, and instead just display the shorter commentary section:

Sounds good to me.  Would you mind installing that change?

I think we should probably just replace README.md with something much
shorter once use-package is in emacs.git.  Instead, we could point to
this URL

    https://elpa.gnu.org/packages/doc/use-package.html

if that is that supposed to be the canonical URL for documentation.

Re: Adding use-package to core

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> And is followed by the entire manual (from the README file).  I wonder
>> if it would be better to set :redeem in the package specification to
                                ^
                                this is a peculiar typo...
>> ignore, and instead just display the shorter commentary section:
>
> Sounds good to me.  Would you mind installing that change?

Can do.

> I think we should probably just replace README.md with something much
> shorter once use-package is in emacs.git.  Instead, we could point to
> this URL
>
>     https://elpa.gnu.org/packages/doc/use-package.html
>
> if that is that supposed to be the canonical URL for documentation.

At the very least there should be a note indicating that use-package is
not being developed on GitHub any more, and that bug reports or patches
should be sent to emacs-devel.

Re: [ELPA] New package: use-package

[Stefan Monnier]

> You crystal ball was right! After pruning worktree the command worked,
> but I am quite confused at the output. I've attached the logs for my
> attempt to build, can you please check if I did something incorrectly?

> In particular the build command fails because it complains makeinfo is
> not available, but I clearly have it in path.
[...]
> ~/g/elpa main $ makeinfo --version
> texi2any (GNU texinfo) 6.8
>
> Copyright (C) 2021 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> ~/g/elpa main $ make build/use-package
> emacs --batch -l /home/payas/git/elpa/admin/elpa-admin.el       \
>          -f elpaa-batch-make-one-package use-package
> Updating worktree in "/home/payas/git/elpa/packages/use-package/"
> Updated use-package:
> Auto-merging use-package-core.el
> Merge made by the 'ort' strategy.
>  README.md            | 4 ++--
>  use-package-core.el  | 4 ++--
>  use-package-tests.el | 7 +++++++
>  3 files changed, 11 insertions(+), 4 deletions(-)
>
> ======== Building tarball archive-devel/use-package-2.4.4.0.20221103.163652.tar...
> Build error for archive-devel/use-package-2.4.4.0.20221103.163652.tar: (error "Error-indicating exit code in elpaa--call-sandboxed:
> bwrap: execvp makeinfo: No such file or directory
> ")
> ######## Build of package archive-devel/use-package-2.4.4.0.20221103.163652.tar FAILED!!

The problem comes from `bwrap` here, which our scripts use to
try and protect `elpa.gnu.org` from mishaps.  Not sure why the command
run from `bwrap` can't find `makeinfo`.  Maybe your `makeinfo` is not in
one of the directories that are accessible within the sandbox (see
`elpaa--sandbox-ro-binds` in `.../elpa/admin/elpa-admin.el`)?
You should be able to circumvent the problem by editing `elpa-config`
and adding

    (sandbox nil)

to it.

> Also make after build only seems to build setup-ox-hugo.el.
[...]
> ~/g/elpa main $ make packages/use-package
> Generating description file packages/use-package/use-package-pkg.el
> emacs --batch -l admin/elpa-admin.el                               \
>          -f elpaa-batch-generate-autoloads packages/use-package/use-package-autoloads.el
>   INFO     Scraping files for loaddefs...
>   INFO     Scraping files for loaddefs...done
>   GEN      use-package-autoloads.el
> Byte compiling packages/use-package/bind-chord.el
> Unable to activate package `use-package'.
> Required package `bind-key-2.4' is unavailable
> Byte compiling packages/use-package/bind-key.el
> Unable to activate package `use-package'.
> Required package `bind-key-2.4' is unavailable
> Byte compiling packages/use-package/doc/setup-ox-hugo.el
> Unable to activate package `use-package'.
> Required package `bind-key-2.4' is unavailable
>
> In toplevel form:
> packages/use-package/doc/setup-ox-hugo.el:192:51: Warning: reference to free variable `ox-hugo-default-lisp-directory'
> packages/use-package/doc/setup-ox-hugo.el:215:21: Warning: reference to free variable `org-emphasis-regexp-components'
> packages/use-package/doc/setup-ox-hugo.el:222:33: Warning: Unused lexical argument `file'
> packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
> packages/use-package/doc/setup-ox-hugo.el:224:4: Error: `add-to-list' can't use lexical var `ob-lang-alist'; use `push' or `cl-pushnew'
> packages/use-package/doc/setup-ox-hugo.el:230:56: Warning: Unused lexical argument `body'
> packages/use-package/doc/setup-ox-hugo.el:238:11: Warning: assignment to free variable `org-confirm-babel-evaluate'
> packages/use-package/doc/setup-ox-hugo.el:241:11: Warning: assignment to free variable `org-export-headline-levels'
> packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: reference to free variable `org-export-exclude-tags'
> packages/use-package/doc/setup-ox-hugo.el:242:19: Warning: assignment to free variable `org-export-exclude-tags'
>
> In end of data:
> packages/use-package/doc/setup-ox-hugo.el:238:40: Warning: the function `ox-hugo-org-confirm-babel-evaluate-fn' is not known to be defined.
> packages/use-package/doc/setup-ox-hugo.el:218:4: Warning: the function `org-set-emph-re' is not known to be defined.
> packages/use-package/doc/setup-ox-hugo.el:208:4: Warning: the function `org-hugo-export-wim-to-md' is not known to be defined.
> packages/use-package/doc/setup-ox-hugo.el:75:49: Warning: the function `vc-git-root' is not known to be defined.
> make: *** [GNUmakefile:119: packages/use-package/doc/setup-ox-hugo.elc] Error 

While the bulk of the output comes from `setup-ox-hugo.el` it's not the
only file compile, as we can see several messages of the form:

    Byte compiling packages/use-package/<foo>.el

It's just that most of the files have been cleaned up not to emit
warnings, whereas `setup-ox-hugo.el` has not enjoyed the same care.

> There are also couple of errors, there are couple of errors too, and
> I'm not sure if fixing them is worth it.

The overall error is because of the `add-to-list` error above
encountered during compilation of `setup-ox-hugo.el`.
Should be easy to fix, so I'd encourage you to fix those errors and
warnings, especially since the rest of the code is "warning-free".

> My understanding is that we only need to add copyrights to the file
> because entire repo is cloned to GNU machines. But even after adding
> copyright headers, IMO adding doc/* to :ignored-files is the right thing
> to do as it does not serve users directly.

Indeed the two choices are independent.  Whether to include the `doc`
subdir in the tarball depends on whether the increased tarball size is
a problem and whether that `doc` is relevant for users of `use-package`.
I don't know enough about what that `doc` holds to give
a good recommendation.

> ~/g/elpa main ?1 2.7s [2] make build/bind-key
> emacs --batch -l /home/payas/git/elpa/admin/elpa-admin.el       \
>          -f elpaa-batch-make-one-package bind-key
> Cloning branch bind-key:
> Preparing worktree (new branch 'externals/bind-key')
> branch 'externals/bind-key' set up to track 'origin/externals/bind-key'.
> HEAD is now at 0be480ea77 Merge pull request #1009 from andreyorst/face-spec-set-third-argument
>
> ======== Building tarball archive-devel/bind-key-2.4.1.0.20221029.145719.tar...
> ######## Built new package archive-devel/bind-key-2.4.1.0.20221029.145719.tar!
> ======== Building tarball archive/bind-key-2.4.1.tar...
> ######## Built new package archive/bind-key-2.4.1.tar!

This worked.

> ~/g/elpa main ?1 1.2s ? make packages/bind-key

Since both use the same repository, they contain the same files, and so
compiling `bind-key` or compiling `use-package` should basically do the same.
[ This "compiling" is for in-place installation of the package, where
  we can't really install `use-package` without also installing
  `bind-key` and vice-versa.  ]


        Stefan

Re: [ELPA] New package: use-package

[Stefan Monnier]

> diff --git a/elpa-packages b/elpa-packages
> index afd9b1a528..4f1a86d6a8 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -86,9 +86,6 @@
>    :auto-sync nil)
>   ("beacon"		:url "https://github.com/Malabarba/beacon"
>    :auto-sync t)
> - ;;("bind-key"         :url "https://github.com/jwiegley/use-package"
> - ;; :ignored-files ("LICENSE" "doc" "Makefile*" "bind-chords.el" "use-package*")
> - ;; :auto-sync t)
>   ("blist"		:url "https://gitlab.com/mmemmew/blist"
>    :doc "blist.texinfo"
>    :readme "README.org"

AFAICT `use-package.el` requires the `bind-key` package, so if we don't
add a `bind-key` package, `use-package` will not be installable.

> @@ -739,11 +736,12 @@
>    :readme "README.md")
>   ("uniquify-files"	:url nil)
>   ("url-http-ntlm" 	:url nil)
> - ;;("use-package"		:url "https://github.com/jwiegley/use-package"
> - ;; :ignored-files ("LICENSE" "bind-*" "use-package-chords.el")
> - ;; :doc "use-package.texi"
> - ;; :news "NEWS.md"
> - ;; :auto-sync t)
> + ("use-package"	:url "https://github.com/jwiegley/use-package"
> +  :auto-sync t
> +  :ignored-files ("LICENSE" "bind-*" "use-package-chords.el" "use-package-ensure-system-package.el" ".travis.yml")

Is there any harm in including "use-package-ensure-system-package.el" and
".travis.yml"?


        Stefan

Re: [ELPA] New package: use-package

[Payas Relekar]

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

>> diff --git a/elpa-packages b/elpa-packages
>> index afd9b1a528..4f1a86d6a8 100644
>> --- a/elpa-packages
>> +++ b/elpa-packages
>> @@ -86,9 +86,6 @@
>>    :auto-sync nil)
>>   ("beacon"		:url "https://github.com/Malabarba/beacon"
>>    :auto-sync t)
>> - ;;("bind-key"         :url "https://github.com/jwiegley/use-package"
>> - ;; :ignored-files ("LICENSE" "doc" "Makefile*" "bind-chords.el" "use-package*")
>> - ;; :auto-sync t)
>>   ("blist"		:url "https://gitlab.com/mmemmew/blist"
>>    :doc "blist.texinfo"
>>    :readme "README.org"
>
> AFAICT `use-package.el` requires the `bind-key` package, so if we don't
> add a `bind-key` package, `use-package` will not be installable.

Right, once upstream is fixed, I'll prepare a patch with binc-key
package for ELPA as well. That was definitely an oversight on my part
because my local build following the instructions failed.

>> @@ -739,11 +736,12 @@
>>    :readme "README.md")
>>   ("uniquify-files"	:url nil)
>>   ("url-http-ntlm" 	:url nil)
>> - ;;("use-package"		:url "https://github.com/jwiegley/use-package"
>> - ;; :ignored-files ("LICENSE" "bind-*" "use-package-chords.el")
>> - ;; :doc "use-package.texi"
>> - ;; :news "NEWS.md"
>> - ;; :auto-sync t)
>> + ("use-package"	:url "https://github.com/jwiegley/use-package"
>> +  :auto-sync t
>> +  :ignored-files ("LICENSE" "bind-*" "use-package-chords.el" "use-package-ensure-system-package.el" ".travis.yml")
>
> Is there any harm in including "use-package-ensure-system-package.el" and
> ".travis.yml"?

No harm really. "use-package-ensure-system-package.el" was ignored
because MELPA recipe ignores it, and ".travis.yml" was ignored by my own
common sense :)

Happy to be corrected by John (or anyone with inside knowledge).
--

Re: [ELPA] New package: use-package

[Stefan Monnier]

> No harm really. "use-package-ensure-system-package.el" was ignored
> because MELPA recipe ignores it, and ".travis.yml" was ignored by my own
> common sense :)
>
> Happy to be corrected by John (or anyone with inside knowledge).

Usually we prefer to err on the side of including useless files and only
ignoring harmful files (often the harm is that it unduly increases the
size of the tarball).  E.g. many packages ignore the GPLv3 LICENSE file
because its size is considered too large in proportion to the rest of
the package (a copy of the GPLv3 already comes with Emacs), but in the
case of `use-package` I suspect that the tarball is large enough that
including LICENSE wouldn't do much harm.


        Stefan

Re: [ELPA] New package: use-package

[Payas Relekar]

[-- Attachment #1: Type: text/plain, Size: 100 bytes --]

It seems there's some issue with my mails going through.

Here's another attempt with the patch.
--

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-use-package-New-package.patch --]
[-- Type: text/x-patch, Size: 1564 bytes --]

From c96ca180028faaada941129d603c715965e471ad Mon Sep 17 00:00:00 2001
From: Payas Relekar <relekarpayas@gmail.com>
Date: Tue, 25 Oct 2022 10:51:57 +0530
Subject: [PATCH] elpa-packages (use-package): New package

---
 elpa-packages | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/elpa-packages b/elpa-packages
index afd9b1a528..4f1a86d6a8 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -86,9 +86,6 @@
   :auto-sync nil)
  ("beacon"		:url "https://github.com/Malabarba/beacon"
   :auto-sync t)
- ;;("bind-key"         :url "https://github.com/jwiegley/use-package"
- ;; :ignored-files ("LICENSE" "doc" "Makefile*" "bind-chords.el" "use-package*")
- ;; :auto-sync t)
  ("blist"		:url "https://gitlab.com/mmemmew/blist"
   :doc "blist.texinfo"
   :readme "README.org"
@@ -739,11 +736,12 @@
   :readme "README.md")
  ("uniquify-files"	:url nil)
  ("url-http-ntlm" 	:url nil)
- ;;("use-package"		:url "https://github.com/jwiegley/use-package"
- ;; :ignored-files ("LICENSE" "bind-*" "use-package-chords.el")
- ;; :doc "use-package.texi"
- ;; :news "NEWS.md"
- ;; :auto-sync t)
+ ("use-package"	:url "https://github.com/jwiegley/use-package"
+  :auto-sync t
+  :ignored-files ("LICENSE" "bind-*" "use-package-chords.el" "use-package-ensure-system-package.el" ".travis.yml")
+  :readme "README.md"
+  :doc "use-package.texi"
+  :news "NEWS.md")
  ("validate"		:url "https://github.com/Malabarba/validate.el")
  ("valign"		:url "https://github.com/casouri/valign")
  ("vc-backup"		:url "https://git.sr.ht/~pkal/vc-backup"
-- 
2.37.3

Re: [ELPA] New package: use-package

[Eli Zaretskii]

> From: Payas Relekar <relekarpayas@gmail.com>
> Cc: John Wiegley <johnw@gnu.org>
> Date: Tue, 25 Oct 2022 18:33:10 +0530
> 
> It seems there's some issue with my mails going through.

There's no issue.  You are not subscribed to the list, so each message
you post needs to be reviewed by the list moderator (a human) and
approved.

Please consider subscribing, especially if you intend to post
frequently enough.

Re: [ELPA] New package: use-package

[Payas Relekar]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Payas Relekar <relekarpayas@gmail.com>
>> Cc: John Wiegley <johnw@gnu.org>
>> Date: Tue, 25 Oct 2022 18:33:10 +0530
>>
>> It seems there's some issue with my mails going through.
>
> There's no issue.  You are not subscribed to the list, so each message
> you post needs to be reviewed by the list moderator (a human) and
> approved.
>
> Please consider subscribing, especially if you intend to post
> frequently enough.

That makes sense. emacs-devel is very high traffic (compared to my tiny
inbox) so I previously had to unsubscribe. But this makes sense. I'll
just wait next time onwards :)

--

[ELPA] New package: use-package

[Payas Relekar]

[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]

As per previous discussion, here is a patch to submit "use-package" to
GNU ELPA.

According to John Wiegley (cc'd) copyright assignment is done, so there
should be nothing to stop getting use-package added to ELPA.

Since John personally cannot commit time to undertake the janitorial
work to do necessary changes and upstream it, I would like to carry out
that task.
However, considering my personal time and elisp skills, not to mention
understanding of use-package codebase is less than perfect at the
moment, it might take me a while, and definitely will not be completed
before 29 branch-off. If someone else wants to pick up the pace, please
feel free to take over.

As for any changes necessary to get accepted to ELPA, please let me
know.

I have tried to go through ELPA manual and refer to MELPA recipe as well
as few other packages already in ELPA package list, but it very possible
to have missed something. I'm following these instructions, but since I
don't have an account on ELPA, I'd like to ask how to proceed further.

1. Notify emacs-devel@gnu.org.
2. Push your package's code to its branch on elpa.git with:

   $ git push elpa <mybranch>:refs/heads/externals/<pkgname>

   where =<mybranch>= will probably be =master= for most people.
   [ Note: The name "externals/" is the result of an accident of history.  ]

3. Edit the =elpa-packages= file to add an entry for =<pkgname>=.
   It has to have an =:url= property specified but that
   property can be nil.
4. =git add elpa-packages=, =git commit= and =git push=.

If you don't have push access to the repository, someone will do steps
2-4 for you.

Please be kind for any rookie mistakes, this is my first time
contributing to a GNU project.

Also, I do not have any copyright assignment papers signed, but I also
do not have any changes in use-package or any GNU project just yet. Is
it needed for ELPA patch? It is well under 15 lines, but I'd rather be
safe.

Thanks,
Payas

--
<#part type="text/x-patch"
filename="~/git/elpa/0001-elpa-packages-use-package-New-package.patch"
disposition=attachment>
<#/part>

[-- Attachment #2: Type: text/html, Size: 2563 bytes --]

Re: [ELPA] New package: use-package

[Daniel Martín]

Payas Relekar <relekarpayas@gmail.com> writes:

> However, considering my personal time and elisp skills, not to mention
> understanding of use-package codebase is less than perfect at the
> moment, it might take me a while, and definitely will not be completed
> before 29 branch-off. If someone else wants to pick up the pace, please
> feel free to take over.

If I'm not mistaken, proposing the package for GNU ELPA inclusion should
not conflict with the Emacs 29 release branch cut.

I don't know what was the final decision about use-package, I think it's
a good package to have in Core, but I agree that it's a bit late to
prepare all the manuals, etc. that should accompany it before Emacs 29.

Re: [ELPA] New package: use-package

[Payas Relekar]

Daniel Martín <mardani29@yahoo.es> writes:

> Payas Relekar <relekarpayas@gmail.com> writes:
>
>> However, considering my personal time and elisp skills, not to mention
>> understanding of use-package codebase is less than perfect at the
>> moment, it might take me a while, and definitely will not be completed
>> before 29 branch-off. If someone else wants to pick up the pace, please
>> feel free to take over.
>
> If I'm not mistaken, proposing the package for GNU ELPA inclusion should
> not conflict with the Emacs 29 release branch cut.

Correct, hence the attempt to submit to ELPA.

Original mail meant inclusion to upstream emacs.git, just to set
expectations right, considering there is lot of excitement in the air
with eglot and tree-sitter.

> I don't know what was the final decision about use-package, I think it's
> a good package to have in Core, but I agree that it's a bit late to
> prepare all the manuals, etc. that should accompany it before Emacs 29.

Indeed. If I end up doing the work alone, it *will* take a lot of time,
but I hope nobody minds :)
--