cask / epl

Emacs Package Library

EPL — Emacs Package Library

EPL provides a convenient high-level API for various package.el versions, and aims to overcome its most striking idiocies.

Installation

Install from MELPA or Marmalade. The former is strongly recommended.

In your Cask:

(source gnu)
(source melpa)

(depends-on "epl")

EPL supports GNU Emacs 24 with the built-in package.el library. EPL should also work on GNU Emacs 23 with the 3rd party package.el, but this combination is not regularly tested anymore. Other versions of Emacs, and other flavors of Emacs (e.g. XEmacs, Aquamacs, etc.) are not supported.

Usage

Refer to the commentary of epl.el for a list of functions, and to the docstrings of these functions for usage instructions.

We may add a list of all functions to this README, but this is not exactly easy. Pull requests welcome.

License

EPL is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

EPL is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

See COPYING for the complete text of the license.

epl's Issues

Delete package function does not update package alist

In Emacs Snapshot, the deleted package is removed from package-alist using:

;; Update package-alist.
(let* ((name (package-desc-name pkg-desc))
       (pkgs (assq name package-alist)))
  (delete pkg-desc pkgs)
  (unless (cdr pkgs)
    (setq package-alist (delq pkgs package-alist))))

The package-alist is however not updated in older versions of Emacs, such as 24.3.1.

What do you say about adding the above snippet to the legacy version?

Reflux Issue 7 -- EPL Upgrade

[see https://github.com//issues/7]

Just attempted a clean install of Cider

• emacs 24.3.1
• Fedora 19 64-bit

As per @lunaryorn comment:
@cch1 @davidboles Unlikely. This issue has been fixed months ago. EPL does not clear package-archives anymore.
Please provide more details, including tracebacks. Ideally, open a new issue.

--- Warnings 
Warning (emacs): Unable to activate package `pkg-info'.
Required package `dash-1.6.0' is unavailable

--- Compile Log
Leaving directory `/home/mark/.emacs.d/elpa/epl-20140211.524'

Compiling file /home/mark/.emacs.d/elpa/epl-20140211.524/epl-pkg.el at Wed Feb 19 15:01:51 2014
Entering directory `/home/mark/.emacs.d/elpa/epl-20140211.524/'

Compiling file /home/mark/.emacs.d/elpa/epl-20140211.524/epl.el at Wed Feb 19 15:01:51 2014

Compiling no file at Wed Feb 19 15:01:52 2014
Leaving directory `/home/mark/.emacs.d/elpa/pkg-info-20131101.408'

Compiling file /home/mark/.emacs.d/elpa/pkg-info-20131101.408/pkg-info-pkg.el at Wed Feb 19 15:01:52 2014
Entering directory `/home/mark/.emacs.d/elpa/pkg-info-20131101.408/'

Compiling file /home/mark/.emacs.d/elpa/pkg-info-20131101.408/pkg-info.el at Wed Feb 19 15:01:52 2014
pkg-info.el:48:1:Error: Cannot open load file: dash

Compiling no file at Wed Feb 19 15:01:53 2014
Leaving directory `/home/mark/.emacs.d/elpa/dash-20140214.321'

Compiling file /home/mark/.emacs.d/elpa/dash-20140214.321/dash-pkg.el at Wed Feb 19 15:01:53 2014
Entering directory `/home/mark/.emacs.d/elpa/dash-20140214.321/'

Compiling file /home/mark/.emacs.d/elpa/dash-20140214.321/dash.el at Wed Feb 19 15:01:53 2014

Compiling no file at Wed Feb 19 15:01:54 2014
Leaving directory `/home/mark/.emacs.d/elpa/clojure-mode-20140201.649'

Compiling file /home/mark/.emacs.d/elpa/clojure-mode-20140201.649/clojure-mode-pkg.el at Wed Feb 19 15:01:54 2014
Entering directory `/home/mark/.emacs.d/elpa/clojure-mode-20140201.649/'

Compiling file /home/mark/.emacs.d/elpa/clojure-mode-20140201.649/clojure-mode.el at Wed Feb 19 15:01:54 2014

Compiling no file at Wed Feb 19 15:01:57 2014
Leaving directory `/home/mark/.emacs.d/elpa/cider-20140211.2319'

Compiling file /home/mark/.emacs.d/elpa/cider-20140211.2319/cider-client.el at Wed Feb 19 15:01:57 2014
Entering directory `/home/mark/.emacs.d/elpa/cider-20140211.2319/'

In end of data:
cider-client.el:173:1:Warning: the following functions are not known to be defined:
    cider-eval-ns-form, cider-load-file-handler,
    cider-interrupt-handler

Compiling file /home/mark/.emacs.d/elpa/cider-20140211.2319/cider-eldoc.el at Wed Feb 19 15:01:57 2014

Compiling file /home/mark/.emacs.d/elpa/cider-20140211.2319/cider-interaction.el at Wed Feb 19 15:01:57 2014
cider-interaction.el:90:1:Warning: defcustom for
    `cider-prompt-save-file-on-load' fails to specify containing group
cider-interaction.el:90:1:Warning: defcustom for
    `cider-prompt-save-file-on-load' fails to specify containing group

In cider-default-err-handler:
cider-interaction.el:764:18:Warning: reference to free variable
    `cider-repl-popup-stacktraces'

In cider-insert-in-repl:
cider-interaction.el:1038:13:Warning: reference to free variable `arg'

In end of data:
cider-interaction.el:1329:1:Warning: the following functions are not known to be defined:
    cider-repl-set-ns, cider-find-or-create-repl-buffer,
    cider-repl-clear-buffer, cider-repl-emit-result,
    cider-repl-emit-output, cider-repl-emit-interactive-output,
    cider-repl-return, cider-repl--replace-input

Compiling file /home/mark/.emacs.d/elpa/cider-20140211.2319/cider-macroexpansion.el at Wed Feb 19 15:01:57 2014

Compiling file /home/mark/.emacs.d/elpa/cider-20140211.2319/cider-mode.el at Wed Feb 19 15:01:58 2014

Compiling file /home/mark/.emacs.d/elpa/cider-20140211.2319/cider-pkg.el at Wed Feb 19 15:01:58 2014

Compiling file /home/mark/.emacs.d/elpa/cider-20140211.2319/cider-repl.el at Wed Feb 19 15:01:58 2014
cider-repl.el:39:1:Error: Cannot open load file: pkg-info

Compiling file /home/mark/.emacs.d/elpa/cider-20140211.2319/cider-selector.el at Wed Feb 19 15:01:58 2014
cider-selector.el:35:1:Error: Cannot open load file: pkg-info

Compiling file /home/mark/.emacs.d/elpa/cider-20140211.2319/cider-util.el at Wed Feb 19 15:01:58 2014

Compiling file /home/mark/.emacs.d/elpa/cider-20140211.2319/cider.el at Wed Feb 19 15:01:58 2014
cider.el:60:1:Error: Cannot open load file: pkg-info

Compiling file /home/mark/.emacs.d/elpa/cider-20140211.2319/nrepl-client.el at Wed Feb 19 15:01:58 2014

In end of data:
nrepl-client.el:874:1:Warning: the following functions are not known to be defined:
    cider-repl-emit-interactive-output, cider-make-repl

Changing package dir initializes the default elpa dir

Is there any reason that the function epl-change-package-dir calls epl-initialize? If you call epl-reset, this will initialize in the default elpa dir, which is not what I want.

Is there any reason it works like that or can it be removed?

Possible conflict with built-in package.el

There's a version of package.el that's bundled with EPL and compiling that package-legacy.el overrides the functions definitions from package.el (or a least the byte compiler seems to think so, since that file is not yet loaded):

In package-untar-buffer:
package-legacy.el:582:8:Warning: function package-untar-buffer used to take 1
    argument, now takes 0

In package-refresh-contents:
package-legacy.el:1075:28:Warning: `condition-case-no-debug' is an obsolete
    alias (as of 24.1); use `condition-case-unless-debug' instead.

In package-menu-describe-package:
package-legacy.el:1385:8:Warning: function package-menu-describe-package used
    to take 0-1 arguments, now takes 0

Not sure if that's a real problem, but distributing an old package.el seems like a recipe for problems :-) I guess you do it for compatibility with Emacs 23?

Epl find available packages broken on snapshot

@lunaryorn,

It seems that epl-find-available-packages behaves differently on 24.3.1 and 24.3.50.1.

In 24.3.50.1, if you have installed a package with the most recent version available, then it will not be added to package-archive-contents when you call (package-refresh-contents). The function epl-find-available-packages checks if the package is in package-archive-contents, which it might not be.

Here's some code to reproduce the issue:

(let ((flycheck (assq 'flycheck package-alist)))
  (let (package-alist package-archive-contents)
    (push flycheck package-alist)
    (package-refresh-contents)
    (print (format "in package-alist: %s"
                   (not (not (assq 'flycheck package-alist)))))
    (print (format "in package-archive-contents: %s"
                   (not (not (assq 'flycheck package-archive-contents)))))))

The package is however available in package-alist. What we could do is that we extend epl-find-available-packages so that it first checks package-archive-contents and then package-alist.

What do you think?

Tag for version 0.8 has strange name

Version 0.8 is tagged 71d8098 instead of 0.8. Please tag this commit as 0.8. Thanks.

Vagrantify :)

Setup Vagrant to create a local virtual machine to test against all supported Emacs versions. Use the same provisioning script as on Travis CI.

Send a recipe suggestion to el-get.

See issue clojure-emacs/cider#398 for detail.

Package requirements recursively

In Cask, we need a function that returns a package's requirements recursively. Either we add a new function or we extend epl-package-requirements to take a second optional recusive argument.

I've looked a bit at what package.el provides us with. In snapshot, we could probably use package-compute-transaction, but this does not exist in stable Emacs. Perhaps there's some other function we could use there?

But it seems to me that it's quite easy to write this function ourself.

@lunaryorn What do you think about this?

Byte compilation error

I got this error while installing the latest version from MELPA:

Compiling file /Users/bozhidar/.emacs.d/elpa/epl-20130914.1604/epl.el at Fri Sep 27 14:50:33 2013
epl.el:105:1:Error: Symbol's function definition is void: epl-error

No output

This package should be completely silent and print nothing. See cask/cask#47

Epl install file

package.el has a function called package-install-file, which does not exist in Epl. Looking at the source of package-install-file it's an interactive function, so I wonder if we should use that directly with a simple alias or if we should write it from scratch using non interactive functions in package.el.

Thoughts?

Error on epl-upgrade

Running epl-upgrade results in an error(MELPA repo, Emacs 24.3):

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("\\`https?:" nil)
  package-download-tar(web-mode "20131007.2108")
  package-download-transaction((web-mode))
  package-install(web-mode)
  epl-package-install([cl-struct-epl-package web-mode [(20131007 2108) nil "major mode for editing html templates [github]" tar "melpa"]])
  epl-upgrade()
  eval((epl-upgrade) nil)
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  ad-Orig-call-interactively(eval-last-sexp nil nil)
  call-interactively(eval-last-sexp nil nil)

Add function list to README?

We should mention all functions in README, just like dash.el does.

@rejeep You did that for f.el, so do you have any hints?

Documentation on what epl adds/replaces?

I'm curious if there's anywhere that I can learn more about the advantages of epl over current package.el, especially given the emergence of systems like straight and use-package.
Thanks in advance!

Support package-archive-priorities

Hello,

@fommil at Silex/package-utils#4 reported an issue that I think is in fact an epl issue 😉

Basically, epl-find-upgrades (and thus epl-upgrade) ignores package-archive-priorities and always finds the latest version from all archives.

It apparently has the effect that upgrading packages through epl has not the same effect as upgrading packages from package-list-package.

That being said, I'm not entirely sure my description above is accurate, but it's what it feels like.

If you point me to the right direction I can make a PR.

Invalid package requires error handling

Calling epl-package-from-file on a file with an invalid Package-Requires header, for example

;; Package-Requires: ((s "1.7.0") (dash "2.2.0")

will result in the error End of file during parsing. This error can be very difficult to track in packages using EPL.

I suggest handling the error in EPL and raise a proper error in such case.

See cask/cask#284

(file-error "http://stable.melpa.org/packages/epl-0.8.el" "Not found")

I am getting this error whenever I try to install helm-projectile or for that matter any package that requires epl.

(file-error "http://stable.melpa.org/packages/epl-0.8.el" "Not found")

Wrong type argument arrayp

This happens with latest EPL:

Debugger entered--Lisp error: (wrong-type-argument arrayp f)
  epl-package--package-desc-p(f)
  epl-package-install(f)

I will look at this later. @lunaryorn is this is an issue for trunk as well?

(we really need some tests...)

Create packages from TARs and package descriptors

EPL should provide means to create epl-package objects from TARs and package descriptor files (i.e. foo-pkg.el).

The former should be part of epl-package-from-file, and the latter should live in a separate function, e.g. epl-package-parse-descriptor.

Epl sandbox

Hey,

I want to be able to perform a "package.el task" for a project and then switch back to the current state. For example:

(epl-sandbox
 (epl-change-package-dir "/path/to")
 (epl-package-install 'foo))

The main reason for this is in Cask so that functions won't affect the global package.el state.

What do you think?