Error on epl-upgrade

[bbatsov]

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)

[rejeep]

Possiby related to #6 (see my comments below)?

[swsnr]

This error is quite strange. It seems to bubble up from package.el actually. The call stack shows, that EPL itself calls package-install with the right package name, and from this point onwards package.el should really just do its job. Which it apparently doesn't in this case…

I'll need to get hands on Emacs 24.3 and try to reproduce this issue myself.

[rejeep]

Same here, I can take a deeper look at it this weekend.

[rejeep]

@bbatsov Is this still an issue? I really cant reproduce this.

[bbatsov]

@rejeep I'll check tomorrow if it's behaving properly.

[pbogdan]

This might be only tangentially related, but I ran into a similar problem (let me know if I should open a separate issue).

I'm not using epl directly but two of my packages which I install via package.el depend on it (in this case nrepl.el and cider). The problem I ran into is that epl resets global package-archives var and sets it to nil, regardless of whether it was previously defined (line 111 in epl.el).

A minimal test case init.el, assuming empty .emacs.d/elpa/

(require 'package)

(add-to-list 'package-archives
             '("marmalade" . "http://marmalade-repo.org/packages/") t)

(add-to-list 'package-archives
              '("melpa" . "http://melpa.milkbox.net/packages/") t)

(package-initialize)

(when (not package-archive-contents)
  (package-refresh-contents))

(defvar my-packages
  '(nrepl)
  "A list of packages to ensure are installed at launch.")

(dolist (p my-packages)
  (when (not (package-installed-p p))
    (package-install p)))

nrepl will pull in pkg-info, which will pull in epl, which will reset package-archives var and make installing any packages impossible from that point on, including completing nrepl installation.

[swsnr]

@pbogdan Oh, sorry. That is a left-over from the days when this library was part of Cask, where we had full control over the package.el environment.

I'll fix that…

[swsnr]

@pbogdan As of 752fae9, EPL does not reset package-archives anymore.

[pbogdan]

Fantastic, cheer @lunaryorn

[bbatsov]

@lunaryorn Seems that you haven't released a new Marmalade package, which is causing problems for everyone using EPL 0.2.

[swsnr]

@bbatsov I'm sorry. I always forget. I wish people would stop using Marmalade.

Unfortunately I'm not going to be at my system anymore until tomorrow morning UTC. I tried to upload the current master from my phone, but marmalade won't accept cvs versions...

@rejeep I made you an owner of the EPL package on Marmalade. Can you create a proper epl release for 0.3 and upload it?

[rejeep]

Done!

@lunaryorn,

You know how I usually do versioning, with Semver. But it seems you have omitted the patch version for EPL? Or do you only add it when you release a patch?

The reason I'm asking is because in my world, the package-archives fix was a bug, hence a patch version on 0.2. But the way EPL was setup with a pre release for 0.3, I guess you didn't have a patch in mind?

[swsnr]

@rejeep Thank you!

I haven't worked out a versioning policy for EPL yet. I mean, it's just three releases yet, and both, API and implementation, are far from stable yet, so there's really little difference between a patch and a minor release. It's in constant flux. I think, Semver is more or less pointless before we have reached 1.0 with a stable API.

But if you want, I can adopt Semver. I'd still bump the version to the next pre-release after a release, though. For patch releases, I'd fork of separate branches from the last release tag, and merge these back into master after the patch release. I think that's a reasonable model for Semver without drawing in the whole complexity of Git Flow.

[swsnr]

By the way, I have closed this issue, since it is fixed now.

[rejeep]

EPL is your baby, so I follow what ever release flow you seem fit.

[swsnr]

@rejeep I'll stick to the current scheme then, as long as things are floating around. It's just simpler, and I currently can't keep the promise of Semver, namely a stable API, anyway. I'm still learning about the user's demands, and the package.el way of doing things, and I expect EPL to change quite a bit.

However, if the package approaches stability and a good API, I'll switch to Semver.

[rejeep]

It's just simpler, and I currently can't keep the promise of Semver, namely a stable API, anyway.

If the project has not hit v1.0 yet, there's no guarantee that the API will not change. That only applies after.

[swsnr]

@rejeep Yes, I know. But if I don't make any promise with regards to features and stability anyway, I just see no point in the difference between patch and minor releases.

[rejeep]

Yeah, just wanted to make sure you knew about that! :)

[davidboles]

I think this issue is still present. I'm setting up a new system and I get the exact same behavior cited above the first time I execute (package-refresh-contents). I'm an "old style" emacs user so I may not be following stuff correctly. That said, I'm not consciously asking for anything but the newest of stuff so if there's been a checkin on marmalade I should be getting it.

[cch1]

I too continue to see this problem. Emacs 24.3 on OSX.

I see it after completely removing the ~/.emacs.d/elpa directory and attempting to install the cider package. The only package archive I have defined in init.el is melpa.milkbox.net

[swsnr]

@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.