See nix-community/emacs-overlay#26

In short, we should probably try to preserve -pre, -rc versions etc.

"should ask melpa/package-build" ~ posted in syl20bnr/spacemacs#15933 (comment) "

Hi, I have a weird GIT-configuration to allow me to run some customized git programs by default.

However, the usual GIT_EXEC_PATH="/usr/lib/git-core" emacs did not work for spacemacs, perhaps because of the timeout wrap around git.

I can make the startup errors go away by replacing command in package-build--run-process ( core/libs/package-build.el ) & in quelpa-build--run-process ( core/libs/quelpa.el ) with: "env" "GIT_EXEC_PATH=/usr/lib/git-core" command

Would it be possible (and sensible) to allow variables to be "known" to the (git) command? So that, for example GIT_EXEC_PATH="/usr/lib/git-core" emacs would work.

One would suspect that setting a version regexp(version-regexp) to a regular expression that can never be matched would remove a broken and unmaintained package from melpa stable. But it appears that forge was unable to do this.

This issues is just to open a discussion about how and if maintainers are able to remove their packages from melpa stable.

cc: @tarsius

On Wednesday I will merge melpa/melpa#8043, adding two new fetchers to package-build.el and Melpa: codeberg and sourcehut. These are similar to the existing github and gitlab fetchers, and you likely can use them the same way in your project. See Melpa's updated README.md for more information about these fetchers.

Please also complete the information about your project at https://github.com/melpa/melpa/wiki/Downstream-Projects to inform us about how it uses Melpa and package-build.el, and how it is affected by breaking changes. There you can also add yourself to a list people to be explicitly pinged about breaking changes. If you know about other downstream projects, then please add links to them as well. Thanks!

@conao3 @jcs090218 @elpaca @progfolio @steckerhalter

Re melpa/melpa#4687

I think there is a problem with package-build which breaks Cask and then EVM:

In toplevel form:
package-build-badges.el:36:1:Error: Symbol's function definition is void: cl-defmethod
Compiling /home/travis/.emacs.d/.cask/24.3/bootstrap/package-build-20180324.2042/package-build-pkg.el...
Compiling /home/travis/.emacs.d/.cask/24.3/bootstrap/package-build-20180324.2042/package-build.el...
In toplevel form:
package-build.el:48:1:Error: Symbol's function definition is void: cl-defmethod
Compiling /home/travis/.emacs.d/.cask/24.3/bootstrap/package-build-20180324.2042/package-recipe-mode.el...
In toplevel form:
package-recipe-mode.el:36:1:Error: Symbol's function definition is void: cl-defmethod
Compiling /home/travis/.emacs.d/.cask/24.3/bootstrap/package-build-20180324.2042/package-recipe.el...
In toplevel form:
package-recipe.el:67:1:Warning: `(rcp package-recipe)' is a malformed function
package-recipe.el:67:15:Warning: reference to free variable
    `package-recipe--working-tree'
package-recipe.el:69:28:Warning: reference to free variable `rcp'
package-recipe.el:71:1:Warning: `(rcp package-recipe)' is a malformed function
package-recipe.el:71:15:Warning: reference to free variable
    `package-recipe--upstream-url'
In end of data:
package-recipe.el:109:1:Warning: the function `cl-defmethod' is not known to
    be defined.
Wrote /home/travis/.emacs.d/.cask/24.3/bootstrap/package-build-20180324.2042/package-recipe.elc
Done (Total of 1 file compiled, 3 failed, 2 skipped)
Symbol's value as variable is void: package-recipe--working-tree
Cask could not be bootstrapped. Try again later, or report an issue at https://github.com/cask/cask/issues

See https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=bb5399e3cd75450db6db9b3c5829f7bd87ca1308

something about how single file packages are being built causes an error when the file is written,

~/s/melpa ❯❯❯ make recipes/ac-haskell-process
 • Building package ac-haskell-process ...
Package: ac-haskell-process
Fetcher: github
Source:  https://github.com/purcell/ac-haskell-process.git

Cloning https://github.com/purcell/ac-haskell-process.git to /Users/d/src/melpa/working/ac-haskell-process/
Built ac-haskell-process in 2.519s, finished at Mon Aug  6 18:54:00 2018
 ✓ Success:
16 -rw-r--r--  1 d  staff   4.6K Aug  6 18:53 packages/ac-haskell-process-20150423.902.el
 8 -rw-r--r--  1 d  staff   350B Aug  6 18:53 packages/ac-haskell-process-20150423.902.entry
 8 -rw-r--r--  1 d  staff   967B Aug  6 18:54 packages/ac-haskell-process-badge.svg
 8 -rw-r--r--  1 d  staff   289B Aug  6 18:53 packages/ac-haskell-process-readme.txt

~/s/melpa ❯❯❯ make recipes/ac-haskell-process
 • Building package ac-haskell-process ...
Package: ac-haskell-process
Fetcher: github
Source:  https://github.com/purcell/ac-haskell-process.git

Updating /Users/d/src/melpa/working/ac-haskell-process/
File already exists: /Users/d/src/melpa/packages/ac-haskell-process-20150423.902.el
make: [recipes/ac-haskell-process] Error 255 (ignored)

@tarsius can you do a quick fix for this? i'm guessing the write function just needs a flag set to overwrite now that we're always writing the file.

We currently seem to get multi-file packages that have manifests like this:

(define-package "package-lint" "20200906.512" "A linting library for elisp package authors"
  '((cl-lib "0.5")
    (emacs "24.1")
    (let-alist "1.0.6"))
  :commit "05596996286089acc7693b700c7c31780439e39f" :authors
  (("Steve Purcell" . "[email protected]")
   ("Fanael Linithien" . "[email protected]"))
  :maintainer
  ("Steve Purcell" . "[email protected]")
  :keywords
  ("lisp")
  :url "https://github.com/purcell/package-lint")
;; Local Variables:
;; no-byte-compile: t
;; End:

In Emacs 24.1 and 24.2, this seems to produce errors at install time along the lines of

Invalid function: ("Steve Purcell" . "[email protected]")

An example is here.

Should we be quoting those lists? Feels like it.

@progfolio @conao3 @jcs090218 @dickmao @adisbladis

As promised, here is a heads up about upcoming breaking changes. Originally I wanted to delay merging these changes, until the new version string scheme for snapshots is also ready, to avoid making breaking changes until some obviously exciting new feature arrives.

Finishing that will take longer to complete and even longer to be put into production than I had hoped, and it most likely won't involve any breaking changes, so I have decided to merge these breaking changes now. (Also merging this now will make testing easier, and since any version scheme update will require lots of testing, that is quite welcome.)

I expect these to be the last breaking changes for quite a while. In fact I cannot think of anything that would require breaking changes going forward, and some of these changes actively make future breaking changes less likely.

I plan to merge #66 and #67 in a week. Please try to make any necessary changes before then and be ready to merge them once I have merged these pull-requests. If you need more time, then please let me know.

#67 contains all the commits from #66 because it depends on those. There are two pull-requests because I wanted the commit unique to #67 to be reviewed separately.

Breaking changes:

(This descriptions focus on the breaking effects of these commits. For the why, see the commit messages and pull-requests.)

• 964fdd0 removes package-build-expand-file-specs, which was deprecated in the last release. Yes, that isn't long ago, and I was prepared to keep it around longer, but given that there are other breaking changes, that doesn't make much sense anymore.

• 51e5ccd Many low-level functions used to bind default-directory, making it impossible to override that without redefining each of these functions. Now that variable is bound in package-build--package and package-build--fetch (see later commits about the latter).

• 8377d6a package-build--run-process additionally loses the destination argument.

• 1136c4c Previously the recipe object that was passed around using function arguments only contained information about how to build any version of the package. Now we also store information about what version we are building in it. As a consequence many functions lose version and commit arguments.

  If you use the affected internal functions, then you will have to adjust now. If you calculated, e.g., the version yourself and then passed it to an affected function, then you should be able to just use (progn (oset rcp version (your-calculation)) (the-function rcp)) instead of (the-function rcp (your-calculation)).

  The nice thing about this is that it makes future breaking changes much less likely -- at the cost of a breaking change now.

• ea2406f Clearly separates fetching, version detection and checking out. The functions that do those things continue to be considered internal, and if you use them anyway, then you likely will have to make adjustments now.

  You shouldn't use these functions directly and if you do so anyway, then (1) you should let me know, (2) doing so should become easier due to this change (but is still discouraged).

• 0adc96b Finally packages files specs in recipes get a bit more restrictive. See the commit to learn why we are doing that. This is a breaking change, but it likely won't affect you; in Melpa only three recipes had to be adjusted because of this.

It appears that the time string used in package name is
created based on local time rather than some fixed time
such as Greenwich time. This is now causing problem, because
package that I built has different time string than the one
used by the official melpa packages. For example I just got
the following error when I built all my packages myself:

(Spacemacs) Error:
An error occurred while installing ein
(error: (error Need package ‘request-20190621.1622’, but only 20190621.922 is available))

The official package at melpa.org has 1622 as time string.
Package I built has 922 time string. My time zone is UTC-7.

If package-build.el is modified so that it always uses Greenwich time
rather than local time in package version, then it appears that
I would not run into the problem just described.

Hey @tarsius, I see that the build fails for emacs HEAD due to the following new compilation error:

Compiling package-build.el

In toplevel form:
package-build.el:1219:31: Error: value from call to ‘assq-delete-all’ is unused
make: *** [Makefile:32: package-build.elc] Error 1

I wasn't sure if the correct fix was just to assign the result back to the let-bound var locally, or if it indicates an issue with the logic. Any idea?

Describe issue

I've recently encounter this and wonder if this is the bug from this package.

Loading package information... done ✓
  - Installing package-build (20230206.1931)... done ✓

Building artifact elsa (0.1.0)... Copying files (->) and directories (=>)
  from d:/a/Elsa/Elsa/
  to c:/Users/RUNNER~1/AppData/Local/Temp/elsalXxwCq/elsa-0.1.0
    elsa-analyser.el -> elsa-analyser.el
    elsa-check.el -> elsa-check.el
    elsa-dependencies.el -> elsa-dependencies.el
    elsa-english.el -> elsa-english.el
    elsa-error.el -> elsa-error.el
    elsa-extension-builtin.el -> elsa-extension-builtin.el
    elsa-extension-cl.el -> elsa-extension-cl.el
    elsa-extension-dash.el -> elsa-extension-dash.el
    elsa-extension-eieio.el -> elsa-extension-eieio.el
    elsa-extension-elsa.el -> elsa-extension-elsa.el
    elsa-extension-flycheck.el -> elsa-extension-flycheck.el
    elsa-extension-seq.el -> elsa-extension-seq.el
    elsa-extension-subr.el -> elsa-extension-subr.el
    elsa-font-lock.el -> elsa-font-lock.el
    elsa-functions.el -> elsa-functions.el
    elsa-reader.el -> elsa-reader.el
    elsa-rules-list.el -> elsa-rules-list.el
    elsa-ruleset.el -> elsa-ruleset.el
    elsa-scope.el -> elsa-scope.el
    elsa-state.el -> elsa-state.el
    elsa-type-algebra.el -> elsa-type-algebra.el
    elsa-type-helpers.el -> elsa-type-helpers.el
    elsa-typed-builtin.el -> elsa-typed-builtin.el
    elsa-typed-cl.el -> elsa-typed-cl.el
    elsa-typed-eieio.el -> elsa-typed-eieio.el
    elsa-typed-subr.el -> elsa-typed-subr.el
    elsa-typed-syntax.el -> elsa-typed-syntax.el
    elsa-typed-thingatpt.el -> elsa-typed-thingatpt.el
    elsa-types.el -> elsa-types.el
    elsa-variable.el -> elsa-variable.el
  ! bin/elsa -> elsa
  ! bin/elsa.bat -> elsa.bat
  ! d:/a/Elsa/Elsa/elsa.el -> elsa.el
Created elsa-0.1.0.tar containing:
  elsa-0.1.0/
  elsa-0.1.0/elsa
  elsa-0.1.0/elsa-analyser.el
  elsa-0.1.0/elsa-check.el
  elsa-0.1.0/elsa-dependencies.el
  elsa-0.1.0/elsa-english.el
  elsa-0.1.0/elsa-error.el
  elsa-0.1.0/elsa-extension-builtin.el
  elsa-0.1.0/elsa-extension-cl.el
  elsa-0.1.0/elsa-extension-dash.el
  elsa-0.1.0/elsa-extension-eieio.el
  elsa-0.1.0/elsa-extension-elsa.el
  elsa-0.1.0/elsa-extension-flycheck.el
  elsa-0.1.0/elsa-extension-seq.el
  elsa-0.1.0/elsa-extension-subr.el
  elsa-0.1.0/elsa-font-lock.el
  elsa-0.1.0/elsa-functions.el
  elsa-0.1.0/elsa-pkg.el
  elsa-0.1.0/elsa-reader.el
  elsa-0.1.0/elsa-rules-list.el
  elsa-0.1.0/elsa-ruleset.el
  elsa-0.1.0/elsa-scope.el
  elsa-0.1.0/elsa-state.el
  elsa-0.1.0/elsa-type-algebra.el
  elsa-0.1.0/elsa-type-helpers.el
  elsa-0.1.0/elsa-typed-builtin.el
  elsa-0.1.0/elsa-typed-cl.el
  elsa-0.1.0/elsa-typed-eieio.el
  elsa-0.1.0/elsa-typed-subr.el
  elsa-0.1.0/elsa-typed-syntax.el
  elsa-0.1.0/elsa-typed-thingatpt.el
  elsa-0.1.0/elsa-types.el
  elsa-0.1.0/elsa-variable.el
  elsa-0.1.0/elsa.bat
  elsa-0.1.0/elsa.el
Select coding system (default utf-8): 

It's cause by this line,

Since it only happens in Windows 10 (works in Linux and macOS, should this package handle this type of error?

Steps to reproduce

1. You need a Windows 10 machine
2. Install Eask, https://github.com/emacs-eask/cli (Optional, it's easier for me to do it this way)
3. git clone https://github.com/jcs-PR/Elsa/ --branch test/eask
4. Navigate to project Elsa root directory, cd elsa
5. Package it with command eask package

Environment

OS: Windows 10 (x64)
Emacs version: 29.0.50

Propose solution or workaround

 (defun package-build--write-archive-entry (desc)
   (with-temp-file
       (expand-file-name (concat (package-desc-full-name desc) ".entry")
                         package-build-archive-dir)
+    (set-buffer-file-coding-system 'utf-8)
     (pp (cons (package-desc-name    desc)
               (vector (package-desc-version desc)
                       (package-desc-reqs    desc)
                       (package-desc-summary desc)
                       (package-desc-kind    desc)
                       (package-desc-extras  desc)))
         (current-buffer))))

Additional informaion

• GHA log: https://github.com/jcs-PR/Elsa/actions/runs/4147931868

As you can see, it works on Linux and macOS but not Windows.

Seems as something in the recent updates to package-build broke cask. I see this both locally and on travis for my package dajva/rg.el.
This is the error I see:

Wrong number of arguments: #[(rcp version) "!�!�È	
\"�Ä\"�
ÊË$��(ÌÍ\"����4ÎÏ\"�[�GÐU�G���@@	$�[Ð�GW�X���	$�[ÎÓ!,�" [rcp source-dir file-specs files name package-build-default-files-spec package-recipe--working-tree package-build--config-file-list package-build-expand-file-specs eieio-oref ...] 6 ("/home/travis/.emacs.d/.cask/25.3/bootstrap/package-build-20180330.2032/package-build.elc" . 30212)], 5
make: *** [package-test] Error 255

Here is a link to the travis build failures in case it helps: https://travis-ci.org/dajva/rg.el/jobs/360964311

I don't know if the issue is really a cask or package-build issue but cask has not been updated lately so something in this repository seems to be the trigger.

I've been using Cask for 8+ years and recent updates (< 1 year) has broken my emacs config. I've tried to recreate a minimal config for use with Cider and Emacs fails to load

Cask

(source melpa-stable)
(depends-on "cider")
...
(depends-on "package-build")

;; 1+ year ago this worked, but this package has moved
;; (depends-on "package-build" :git "https://github.com/melpa/package-build" :ref "master")

init.el

(require 'package)
(require 'cask "/usr/local/share/emacs/site-lisp/cask/cask.el") ;; fails

"Cannot open load file" "No such file or directory" "package-build"

What am I missing?

Cask has a hard dependency on this package and is dead with this blocker. I've cross-posted this on cask issues as well. Thanks!

--
OS - Mac OS X Monterey - 12.6.6
Emacs Version - 28.2
Cask Version - 0.9.0

I try to build a create recipe. but got error:
Here is the steps:

M-x package-build-create-recipe

(ob-clojure-literate-programming
  :fetcher github
  :repo "stardiviner/ob-clojure-literate-programming")

M-x package-build-cuurrent-recipe

The recipe build result:

;; Please check the following package descriptor.
;; If the correct package description or dependencies are missing,
;; then the source .el file is likely malformed, and should be fixed.
(ob-clojure-literate-programming .
                                 [(20171222 1037)
                                  ((emacs
                                    (24 4))
                                   (org
                                    (9))
                                   (cider
                                    (0 16 0 -4)))
                                  "Clojure's Org-mode Literate Programming." single
                                  ((:commit . "d62c09f2b7837a6ac6022db37b95a21566aaaaa8")
                                   (:keywords "tools")
                                   (:url . "https://github.com/stardiviner/ob-clojure-literate-programming"))])

And the error backtrace:

Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
  package-build--archive-file-name(nil)
  package-build--find-package-file("ob-clojure-literate-programming")
  package-build-current-recipe()
  funcall-interactively(package-build-current-recipe)
  call-interactively(package-build-current-recipe nil nil)
  #f(compiled-function (cmd &optional record-flag keys special) "Execute CMD as an editor command.\nCMD must be a symbol that satisfies the `commandp' predicate.\nOptional second arg RECORD-FLAG non-nil\nmeans unconditionally put this command in the variable `command-history'.\nOtherwise, that is done only if an arg is read using the minibuffer.\nThe argument KEYS specifies the value to use instead of (this-command-keys)\nwhen reading the arguments; if it is nil, (this-command-keys) is used.\nThe argument SPECIAL, if non-nil, means that this command is executing\na special event, so ignore the prefix argument and don't clear it." #<bytecode 0x24db8b>)(package-build-current-recipe nil nil nil)
  ad-Advice-command-execute(#f(compiled-function (cmd &optional record-flag keys special) "Execute CMD as an editor command.\nCMD must be a symbol that satisfies the `commandp' predicate.\nOptional second arg RECORD-FLAG non-nil\nmeans unconditionally put this command in the variable `command-history'.\nOtherwise, that is done only if an arg is read using the minibuffer.\nThe argument KEYS specifies the value to use instead of (this-command-keys)\nwhen reading the arguments; if it is nil, (this-command-keys) is used.\nThe argument SPECIAL, if non-nil, means that this command is executing\na special event, so ignore the prefix argument and don't clear it." #<bytecode 0x24db8b>) package-build-current-recipe)
  apply(ad-Advice-command-execute #f(compiled-function (cmd &optional record-flag keys special) "Execute CMD as an editor command.\nCMD must be a symbol that satisfies the `commandp' predicate.\nOptional second arg RECORD-FLAG non-nil\nmeans unconditionally put this command in the variable `command-history'.\nOtherwise, that is done only if an arg is read using the minibuffer.\nThe argument KEYS specifies the value to use instead of (this-command-keys)\nwhen reading the arguments; if it is nil, (this-command-keys) is used.\nThe argument SPECIAL, if non-nil, means that this command is executing\na special event, so ignore the prefix argument and don't clear it." #<bytecode 0x24db8b>) package-build-current-recipe)
  command-execute(package-build-current-recipe)

Then I did edebug on some functions, belowing are steps:

• [-] edebug
  • [-] package-build-current-recipe
    • [-] package-build--find-package-file
      • [-] (package-build--archive-file-name (assoc name (package-build-archive-alist)))

        • (assoc name (package-build-archive-alist)) -> nil <<-- ERROR (The var name is correct)

          #+begin_src emacs-lisp :results output
          (print
          (assoc 'eldoc-overlay (package-build-archive-alist)))
          (print
          (assoc 'ob-clojure-literate-programming (package-build-archive-alist)))
          #+end_src

          #+RESULTS:
          :
          : (eldoc-overlay . [(20171219 1727) ((emacs (24 3)) (inline-docs (1 0 1)) (quick-peek (1 0))) "Display eldoc with contextual documentation overlay." single ((:commit . "bf0548196a1e0f1c28be38b6f29e1107a49839fd") (:keywords "documentation" "eldoc" "overlay") (:authors ("stardiviner" . "[email protected]")) (:maintainer "stardiviner" . "[email protected]") (:url . "https://github.com/stardiviner/eldoc-overlay"))])
          :
          : nil

          • (package-build-archive-alist)
            • check out function docstring
            • edebug

        • package-build--archive-file-name
          #+begin_src emacs-lisp
          (package-build--archive-file-name)
          #+end_src

I have just formally dropped for Emacs 25, but support for that already broke some time ago. Going forward such breakage should not go unnoticed anymore because I also added a ci workflow that compiles this package using all supported Emacs releases.

/cc @progfolio @conao3 @jcs090218 @dickmao @adisbladis

If a package is built, but then the upstream git repo's default branch is reset to an older revision, this confuses package-build: the correct (older) version is built, but .entry files then exist for both versions, and package-build-dump-archive-contents strictly prefers the higher version when building the full set of available packages.

An example of this problem is with clang-format, where MELPA currently serves version 20191121.1708 for now-non-existent commit 2d6a45, while the latest built version is 20191106.950, for commit e48ff8a.

The solution is probably to always prefer the newest .entry file on disk, rather than the one with the highest version. Can you think of any issues with doing this, @tarsius?

/cc @adisbladis, who reported this to me, since it breaks downstream tooling that looks at metadata (including commits) for packages built by MELPA.

(package-build-all) builds correctly the archive, but it prints:

...
Successfully built 0 of 1 packagesBuilding 1 packages failed:

at the end of the output.

Here is the structure of my personal melpa directory:

<personal-melpa-dir>
 |- archive
 |   \- (empty)
 |- recipes
 |   \- smex
 \- working
     \- (empty)

recipes/smex:

(smex :repo "nonsequitur/smex" :fetcher github)

test.el

#!emacs --script

(add-to-list 'load-path "<package-build-git-repo-dir>")

(require 'package-build)

(setq local-melpa-dir "<personal-melpa-dir>")
(setq package-build-archive-dir (expand-file-name "archive" local-melpa-dir))
(setq package-build-recipes-dir (expand-file-name "recipes" local-melpa-dir))
(setq package-build-working-dir (expand-file-name "working" local-melpa-dir))

(package-build-all)

Here are other things I have noticed:

• The output Successfully built 0 of 1 packages is right beside
  Building 1 packages failed:. Should there be an \n at the end of the
  format template here?
• Is it supposed to be failed instead of invalid here?

package-build commit: 0a22c3f

Hi,
This is related to the recent refactories by @tarsius. The change that renamed package-build-package broke cask again. See cask/cask#426

This function being private is a bit problematic for cask since it depends on this in multiple places. It could still be used from cask anyway of course, but it's not good practice to use private functions in other packages. With the recent refactorings in mind the line between private and public functions might be academic for package-build but my impression is that this instability in the API is temporary and will be better in the future, right?

• Is there any public alternative for this functionality that can be used instead?
• Would you consider making it public again to support the casks use case? It's a huge benefit IMO that cask and melpa are using the same code for creating the packages since that means you can verify and debug your package locally.

@sambrightman: What do you say about this?

The issue

The current release on Melpa Stable dates from January 19th, 2020 with commit bc06686. At that time, package-build still used the macro defmethod from the package cl.

Not only has cl been deprecated in favor of cl-lib, it has now been removed from Emacs. Unfortunately, Cask relies on Melpa Stable to download its required dependencies to run, including the now outdated package-build version. The lack of (require 'cl) in the file crashes version 29 of Emacs.

A fix for that would be to push a newer version to Melpa Stable with the addition of a new tag/release.

Steps to reproduce:

1. Use Emacs 29 on master
2. Perform a clean installation of cask (including removing the .cask directory in $HOME or $HOME/.config/emacs)
3. Run cask init in a dummy project
4. Obsevre Cask crash when it attempts to compile package-build.

Setting ‘package-selected-packages’ temporarily since "emacs -q" would overwrite customizations
Contacting host: stable.melpa.org:443
Parsing tar file... 
Parsing tar file...done
Extracting... \ 
Extracting...done
  INFO     Scraping files for package-build-autoloads.el... 
  INFO     Scraping files for package-build-autoloads.el...done
Checking /home/phundrak/.config/emacs/.cask/29.0/bootstrap/package-build-2.4...
Compiling /home/phundrak/.config/emacs/.cask/29.0/bootstrap/package-build-2.4/package-build-autoloads.el...
Compiling /home/phundrak/.config/emacs/.cask/29.0/bootstrap/package-build-2.4/package-build-badges.el...

In toplevel form:
package-build-badges.el:36:2: Error: Symbol’s function definition is void: defmethod
Compiling /home/phundrak/.config/emacs/.cask/29.0/bootstrap/package-build-2.4/package-build-pkg.el...
Compiling /home/phundrak/.config/emacs/.cask/29.0/bootstrap/package-build-2.4/package-build.el...

In toplevel form:
package-build.el:48:2: Error: Symbol’s function definition is void: defmethod
Compiling /home/phundrak/.config/emacs/.cask/29.0/bootstrap/package-build-2.4/package-recipe-mode.el...

In toplevel form:
package-recipe-mode.el:36:2: Error: Symbol’s function definition is void: defmethod
Compiling /home/phundrak/.config/emacs/.cask/29.0/bootstrap/package-build-2.4/package-recipe.el...

In toplevel form:
package-recipe.el:54:43: Warning: ‘(rcp package-recipe)’ is a malformed function
package-recipe.el:54:12: Warning: reference to free variable ‘package-recipe--working-tree’
package-recipe.el:56:28: Warning: reference to free variable ‘rcp’
package-recipe.el:58:43: Warning: ‘(rcp package-recipe)’ is a malformed function
package-recipe.el:58:12: Warning: reference to free variable ‘package-recipe--upstream-url’

In end of data:
package-recipe.el:54:2: Warning: the function ‘defmethod’ is not known to be defined.
Done (Total of 1 file compiled, 3 failed, 2 skipped)
Package ‘package-build’ installed.

Error: void-variable (package-recipe--working-tree)
  debug-early-backtrace()
  debug-early(error (void-variable package-recipe--working-tree))
  byte-code("\304\10\305 \306\307\310\11\311\"\n\"!#\210\304\13\312 \310\11\313\"\206$\0\314\310\11\315\"\310\11\316\"\"#\210\317\320\321\322!\"\210\317\323\324\322!\"\210\317\325\323\"\210\326\325\327\330#\210\331\322\332\323#\333\322\334\335\336$\207" [package-recipe--working-tree rcp package-build-working-dir package-recipe--upstream-url defmethod (rcp package-recipe) file-name-as-directory expand-file-name eieio-oref name (rcp package-recipe) url format url-format repo defalias package-git-recipe-p eieio-make-class-predicate package-git-recipe package-git-recipe--eieio-childp eieio-make-child-predicate package-git-recipe-child-p make-obsolete "use (cl-typep ... 'package-git-recipe) instead" "25.1" define-symbol-prop cl-deftype-satisfies eieio-defclass-internal (package-recipe) ((tag-regexp :initform "\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} [0-9]\\{2\\}:[0-9]\\{2\\}:[0-9]\\{2\\}\\( [+-][0-9]\\{4\\}\\)?\\)")) nil] 8)
  require(package-recipe)
  eval-buffer(#<buffer  *load*-961490> nil "/home/phundrak/.config/emacs/.cask/29.0/bootstrap/package-build-2.4/package-build.el" nil t)
  load-with-code-conversion("/home/phundrak/.config/emacs/.cask/29.0/bootstrap/package-build-2.4/package-build.el" "/home/phundrak/.config/emacs/.cask/29.0/bootstrap/package-build-2.4/package-build.el" nil t)
  require(package-build)
  (if (featurep pkg) nil (if (package-installed-p pkg) nil (if package-archive-contents nil (package-refresh-contents)) (package-install pkg)) (require pkg))
  (let ((pkg (car --dolist-tail--))) (if (featurep pkg) nil (if (package-installed-p pkg) nil (if package-archive-contents nil (package-refresh-contents)) (package-install pkg)) (require pkg)) (setq --dolist-tail-- (cdr --dolist-tail--)))
  (while --dolist-tail-- (let ((pkg (car --dolist-tail--))) (if (featurep pkg) nil (if (package-installed-p pkg) nil (if package-archive-contents nil (package-refresh-contents)) (package-install pkg)) (require pkg)) (setq --dolist-tail-- (cdr --dolist-tail--))))
  (let ((--dolist-tail-- deps)) (while --dolist-tail-- (let ((pkg (car --dolist-tail--))) (if (featurep pkg) nil (if (package-installed-p pkg) nil (if package-archive-contents nil (package-refresh-contents)) (package-install pkg)) (require pkg)) (setq --dolist-tail-- (cdr --dolist-tail--)))))
  (let (package-alist package-archive-contents (load-path load-path) (package-archives '(("gnu" . "https://elpa.gnu.org/packages/") ("melpa" . "https://stable.melpa.org/packages/"))) (package-user-dir cask-bootstrap-dir) (deps '(s f commander git epl shut-up cl-lib cl-generic package-build eieio ansi))) (package-initialize) (if (version= emacs-version "24.4") (progn (require 'tls) (custom-set-default 'tls-program '("openssl s_client -connect %h:%p -no_ssl3 -no_ssl2 -ign_eof")) (advice--add-function :override (cons #'(lambda nil (symbol-function 'gnutls-available-p)) #'(lambda (gv--val) (fset 'gnutls-available-p gv--val))) #'ignore nil))) (if (version< emacs-version "25.1") (progn (if (package-installed-p 'cl-lib) nil (if package-archive-contents nil (package-refresh-contents)) (package-install 'cl-lib)) (require 'package-recipe (expand-file-name "package-recipe-legacy" cask-directory)) (require 'package-build (expand-file-name "package-build-legacy" cask-directory)))) (let ((--dolist-tail-- deps)) (while --dolist-tail-- (let ((pkg (car --dolist-tail--))) (if (featurep pkg) nil (if (package-installed-p pkg) nil (if package-archive-contents nil (package-refresh-contents)) (package-install pkg)) (require pkg)) (setq --dolist-tail-- (cdr --dolist-tail--))))))
  eval-buffer(#<buffer  *load*-581539> nil "/usr/share/cask/cask-bootstrap.el" nil t)
  load-with-code-conversion("/usr/share/cask/cask-bootstrap.el" "/usr/share/cask/cask-bootstrap.el" nil t)
  require(cask-bootstrap "/usr/share/cask/cask-bootstrap")
  #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_100>(#<buffer  *load*> "/usr/share/cask/cask-cli.el")
  load-with-code-conversion("/usr/share/cask/cask-cli.el" "/usr/share/cask/cask-cli.el" nil t #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_100>)
  command-line--load-script("/usr/share/cask/cask-cli.el")
  command-line-1(("-scriptload" "/usr/share/cask/cask-cli.el" "--" "init"))
  command-line()
  normal-top-level()
Symbol’s value as variable is void: package-recipe--working-tree

By modifying Cask’s Melpa source to melpa.org instead of stable.melpa.org, I no longer have this issue.

Here are two same documents. The document of package-build--artifact-file seems to be wrong.

I'd like to create PR about that but I'm not good at English, so I create this issue instead of PR.

This defcustom runs shell commands when I load the file

(defcustom package-build-timeout-executable
  (let ((prog (or (executable-find "timeout")
                  (executable-find "gtimeout"))))
    (when (and prog
               (string-match-p "^ *-k"
                               (shell-command-to-string (concat prog " --help"))))
      prog))
  "Path to a GNU coreutils \"timeout\" command if available.
This must be a version which supports the \"-k\" option."
  :group 'package-build
  :type '(file :must-match t))

It takes about 0.4s on my machine. This file is loaded among others during cask bootstrap which makes it extremly slow: cask emacs --batch --eval '(kill-emacs)' takes 1 second, from which 2x0.4s is spent in the form above (cask calls emacs twice to get load path and exec path).

When I put (setq-default package-build-timeout-executable "/usr/bin/timeout") in cask-bootstrap.el that alone makes it 4 times faster to start up. Not requiring package.el would save another 2x0.1s for almost instant startup.

Is there anything that can be done here, i.e. lazily determining the binary instead of doing this during load time?

See cask/cask#361

I recently got this error after the latest three commits 6223cae, 4381b1d and 6e48df3. 🤔

Debugger entered--Lisp error: (cyclic-variable-indirection package-build-write-badge-images)
  set-default-toplevel-value(package-build-write-badge-images nil)
  custom-initialize-reset(package-build-write-badge-images (funcall #'(closure (t) nil "" nil)))
  custom-declare-variable(package-build-write-badge-images (funcall #'(closure (t) nil "" nil)) "When non-nil, write badge images alongside package..." :group package-build :type boolean)
  eval-buffer(#<buffer  *load*-543564> nil "/home/runner/work/jcs-elpa/jcs-elpa/.eask/28.2/elp..." nil t)  ; Reading at buffer position 6611
  load-with-code-conversion("/home/runner/work/jcs-elpa/jcs-elpa/.eask/28.2/elp..." "/home/runner/work/jcs-elpa/jcs-elpa/.eask/28.2/elp..." nil t)
  require(package-build)
  eval-buffer(#<buffer  *load*-401696> nil "/home/runner/work/jcs-elpa/jcs-elpa/.eask/28.2/elp..." nil t)  ; Reading at buffer position [20](https://github.com/jcs-emacs/jcs-elpa/actions/runs/5152804123/jobs/9279298809#step:6:21)63
  load-with-code-conversion("/home/runner/work/jcs-elpa/jcs-elpa/.eask/28.2/elp..." "/home/runner/work/jcs-elpa/jcs-elpa/.eask/28.2/elp..." t t)
  require(github-elpa nil t)

See full log https://github.com/jcs-emacs/jcs-elpa/actions/runs/5152804123/jobs/9279298809#step:6:18.

I think the convention is pretty wide spread, all packages that have a binary store it in a bin directory and adding that explicitly complicates things.

I'm pretty sure this wouldn't break anything and it would make packaging simpler. Also it would fix issues like this: cask/cask#395 (comment)

Hi, JCS-ELPA will keep updating the elpa-packages.eld file no matter whether the packages have changed or not. 🤔

Is there a way to make it consistent? Maybe something similar to cl-sort on archive-contents's entries:

I am learning to use package-build to create a personal local melpa containing
only my own packages. In the following simple case, (package-build-all) prints
a "wrong-type-argument stringp" error:

Here is the structure of my personal melpa directory:

<personal-melpa-dir>
 |- archive
 |   \- (empty)
 |- recipes
 |   \- smex
 \- working
     \- (empty)

recipes/smex:

(smex :repo "nonsequitur/smex" :fetcher github)

test.el

#!emacs --script

(add-to-list 'load-path "<package-build-git-repo-dir>")

(require 'package-build)

(setq local-melpa-dir "<personal-melpa-dir>")
(setq package-build-archive-dir (expand-file-name "archive" local-melpa-dir))
(setq package-build-recipes-dir (expand-file-name "recipes" local-melpa-dir))
(setq package-build-working-dir (expand-file-name "working" local-melpa-dir))

(package-build-archive)

When executing (package-build-archive), I expect that it builds smex and put
it in the archive directory.

Instead, the following message is printed:

Error: (wrong-type-argument stringp #s(#s(eieio--class package-github-recipe nil (#s(eieio--class package-git-recipe nil (#s(eieio--class package-recipe nil nil [#s(cl-slot-descriptor name nil t nil) #s(cl-slot-descriptor url nil t nil) #s(cl-slot-descriptor repo nil t nil) #s(cl-slot-descriptor repopage nil t nil) #s(cl-slot-descriptor files nil t nil) #s(cl-slot-descriptor branch nil t nil) #s(cl-slot-descriptor commit nil t nil) #s(cl-slot-descriptor version-regexp nil t nil) #s(cl-slot-descriptor old-names nil t nil)] #s(hash-table size 65 test eq rehash-size 1.5 rehash-threshold 0.8125 data (name 0 url 1 repo 2 repopage 3 files 4 branch 5 commit 6 version-regexp 7 old-names 8)) (package-hg-recipe package-git-recipe) ((:name . name) (:url . url) (:repo . repo) (:repopage . repopage) (:files . files) (:branch . branch) (:commit . commit) (:version-regexp . version-regexp) (:old-names . old-names)) [#s(cl-slot-descriptor stable-p nil t nil) #s(cl-slot-descriptor tag-regexp nil t nil) #s(cl-slot-descriptor repopage-format nil t nil) #s(cl-slot-descriptor url-format nil t nil)] [nil nil nil nil] #s(#6 nil nil nil nil nil nil nil nil nil) (:custom-groups nil :abstract t))) [#s(cl-slot-descriptor name nil t nil) #s(cl-slot-descriptor url nil t nil) #s(cl-slot-descriptor repo nil t nil) #s(cl-slot-descriptor repopage nil t nil) #s(cl-slot-descriptor files nil t nil) #s(cl-slot-descriptor branch nil t nil) #s(cl-slot-descriptor commit nil t nil) #s(cl-slot-descriptor version-regexp nil t nil) #s(cl-slot-descriptor old-names nil t nil)] #s(hash-table size 65 test eq rehash-size 1.5 rehash-threshold 0.8125 data (name 0 url 1 repo 2 repopage 3 files 4 branch 5 commit 6 version-regexp 7 old-names 8)) (package-gitlab-recipe package-github-recipe) ((:name . name) (:url . url) (:repo . repo) (:repopage . repopage) (:files . files) (:branch . branch) (:commit . commit) (:version-regexp . version-regexp) (:old-names . old-names)) [#s(cl-slot-descriptor url-format nil t nil) #s(cl-slot-descriptor repopage-format nil t nil) #s(cl-slot-descriptor tag-regexp "\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} [0-9]\\{2\\}:[0-9]\\{2\\}:[0-9]\\{2\\}\\( [+-][0-9]\\{4\\}\\)?\\)" t nil) #s(cl-slot-descriptor stable-p nil t nil)] [nil nil "\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} [0-9]\\{2\\}:[0-9]\\{2\\}:[0-9]\\{2\\}\\( [+-][0-9]\\{4\\}\\)?\\)" nil] #s(#4 nil nil nil nil nil nil nil nil nil) (:custom-groups nil))) [#s(cl-slot-descriptor name nil t nil) #s(cl-slot-descriptor url nil t nil) #s(cl-slot-descriptor repo nil t nil) #s(cl-slot-descriptor repopage nil t nil) #s(cl-slot-descriptor files nil t nil) #s(cl-slot-descriptor branch nil t nil) #s(cl-slot-descriptor commit nil t nil) #s(cl-slot-descriptor version-regexp nil t nil) #s(cl-slot-descriptor old-names nil t nil)] #s(hash-table size 65 test eq rehash-size 1.5 rehash-threshold 0.8125 data (name 0 url 1 repo 2 repopage 3 files 4 branch 5 commit 6 version-regexp 7 old-names 8)) nil ((:name . name) (:url . url) (:repo . repo) (:repopage . repopage) (:files . files) (:branch . branch) (:commit . commit) (:version-regexp . version-regexp) (:old-names . old-names)) [#s(cl-slot-descriptor stable-p nil t nil) #s(cl-slot-descriptor tag-regexp "\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} [0-9]\\{2\\}:[0-9]\\{2\\}:[0-9]\\{2\\}\\( [+-][0-9]\\{4\\}\\)?\\)" t nil) #s(cl-slot-descriptor repopage-format "https://github.com/%s" t nil) #s(cl-slot-descriptor url-format "https://github.com/%s.git" t nil)] [nil "\\([0-9]\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} [0-9]\\{2\\}:[0-9]\\{2\\}:[0-9]\\{2\\}\\( [+-][0-9]\\{4\\}\\)?\\)" "https://github.com/%s" "https://github.com/%s.git"] #s(#2 nil nil nil nil nil nil nil nil nil) (:custom-groups nil)) "smex" nil "nonsequitur/smex" nil nil nil nil nil nil))
Successfully built 0 of 1 packagesBuilding 1 packages failed:

What should I do to build all the recipes and put the packages in archive?

package-build commit: dfcb7f0

Is it possible that one of the recent changes - db227b0 perhaps? - causes the branch setting in the recipe to be ignored? My package appears to have broken recently and I'm hoping someone can help me figure out what's going on.

There's more info about the concrete problem in melpa/melpa#7652 and jscheid/prettier.el#90.

@purcell 13 years ago we started populating submodules for the benefit of yasnippet and five years ago yasnippet stopped tracking the snippets as a submodule. Instead the documentation now instructs users to install the yasnippet-snippets package separately.

I was just trying to build all the packages on Melpa locally. Building stack-mode failed, because its repository contains a module using a git:// url for a repository on Github, but Github stopped supporting that protocol for security reasons a while ago. (And so did we, but we don't check the urls used for modules.) I recently had to ask the maintainers of another mostly abandoned project to update the urls in .gitmodules to deal with the same issue.

IMO we should stop fetching modules altogether. It is a bit of a security issue. We did it for yasnippet, which no longer needs it. If any other package needs this, then I would consider that a mistake and would encourage its maintainers to change that, likely the same way as yasnippet ultimately did it. But I suspect no other package needs it, so we needlessly fetch modules, and some of them can be large and we have no control over it once a package has been added. Someone might add llvm as a module. There are 109 packages with submodules.

Are you okay with removing support for fetching modules? If it turns out some package actually needs a module to be checked out to build properly, then we could restore support but require that the package's recipe specifies that it needs modules to be checked out.