Welcome to another installment of the “Hard CIDER” series! It’s been way too long since the previous episode and it’s time to get back into action. Today we’re going to discuss the grizzly subject of downgrading CIDER.
Downgrading from a MELPA (snapshot) release
Due to the massive popularity of MELPA1 a many CIDER users are installing it from there and are effectively using a snapshot version. While most of the time the snapshot version works fine2, from time to time you might run into some (small) issues (or epic mistakes) there.3 This section of the article will teach you what to do if you ever end up in this nasty situation - namely downgrade to the latest stable CIDER version.
The downgrade process is really simple. You just need to remove the
ciderto MELPA Stable and reinstall it. Basically you need to do the following:
M-x package-remove cider
(add-to-list 'package-pinned-packages '(cider . "melpa-stable") t)to your Emacs config
- Restart Emacs (or reload your config)
M-x package-install cider
Of course, you’ll have to add the MELPA Stable package repo to your Emacs config if you haven’t done so already. Here’s a complete
package.elconfiguration that you can reuse if you want to:
(require 'package) (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t) (add-to-list 'package-archives '("melpa-stable" . "https://stable.melpa.org/packages/") t) ;; keep the installed packages in .emacs.d (setq package-user-dir (expand-file-name "elpa" user-emacs-directory)) (package-initialize) ;; update the package metadata is the local cache is missing (unless package-archive-contents (package-refresh-contents))
Depending on the type of person you are, you might also want to consider sticking permanently with CIDER pinned to MELPA Stable. Probably the only real problem with this approach is that CIDER releases tend to be few and far in between and you might end up waiting a very long time for some (important) bugfix or a cool new feature.4
Downgrading only cider-nrepl
In case you experience a problem with
cider-nreplyou don’t really need to downgrade the Emacs
ciderpackage - you can simply instruct CIDER to use an older version of the middleware. Let’s assume that
cider-nrepl-0.22-beta6was faulty and we want to go back to
0.22-beta5. Here’s how to do this:
(setq cider-required-middleware-version "0.22-beta5")
After you’ve updated your Emacs config you’ll need to reload it and restart CIDER. Easy-peasy, right?
Downgrading from a Stable Release
Imagine you’re using CIDER 0.21 and for some reason you want to go back to CIDER 0.20. How can you do this?
That’s going to be a pretty short section, as that’s simply not possible. Unfortunately
package.eldoesn’t support the concept of historical versions of a package - there’s always only one version that’s available - the latest one.
Fortunately, I don’t think that this is something that many people needed to do, and if you really have to do it - it’s doable, but painful. You’ll have to do the installation completely manually by cloning the relevant CIDER release tag locally and loading CIDER from there (and potentially some of its dependencies like
I was inspired to write this article after breaking CIDER’s snapshot for a couple of hours on Monday. Shortly afterwards I got asked for the millionth time what to do in this situation and here we are. I also took a moment to add those instructions to the FAQ for future reference.
That’s all I had for you today! Keep hacking!
The underlying cause of this is mostly the fact the historically Emacs package maintainers had a tendency to release extremely rarely (if ever). ↩
I really hope this is not just wishful thinking on my part. ↩
Typically serious problems are addressed within several hours of being reported. ↩
Lately I’ve been trying hard to improve the release cadence, and presently things are looking better on this front. ↩
It’s been quite a while since the last “Meta Reduce” update I wrote and a lot of things have happened in the mean time.1 Let’s go over them real quick.
Frankly, by now I’ve forgotten most of what’s happened. ↩
- Read More
Today marks the release of the first milestone from the nREPL 0.7 series - namely nREPL 0.7.0-alpha1. The highlight of the release is the addition of a native (built-in) EDN transport to complement the default bencode transport that nREPL has shipped since day 1.Read More
Today we’re going to discuss a couple of really simple numeric predicates - namely
Numeric#nonzero?. I assume most Ruby developers are familiar with them, as they represent a popular alternative to doing traditional checks for zero:
if foo == 0 ... if foo.zero? ... if foo != 0 ... if foo.nonzero? ...
So far, so good. Nothing really weird, right? Let’s now take a closer at the two predicate methods:
0.zero? # => true 0.nonzero? #=> nil 1.zero? #=> false 1.nonzero? #=> 1
Now this looks kind of weird… As you can see
nonzero?returns its receiver or
nil. So much for API symmetry. There’s a long weird story behind this inconsistency, and an interesting ticket on Ruby’s bug tracker discussing options how to address it. Most of the time you probably won’t experience any issues related to that inconsistency, but there are certainly cases where it is going to bite you.1
As far as I’m concerned
nonzero?doesn’t exist and I simply use
!zero?all the time. Negative predicates are pretty weird in the first place and I’ve never seen much value in them.2
I’ll end this post with a small challenge for you - what are your favourite examples of API inconsistency in Ruby?
Articles in the Series