cider status

[John D. Hume]

The last (non-authoritative) word on cider on this mailing list[1] was that it is unstable. Is that really the case? Is it just a matter of many packages that depend on it not being updated?

I tried checking the official mailing list[2] and was surprised to find that it's private.

I'm trying to understand this because I submitted a recipe to MELPA, and they will no longer accept packages that depend on nrepl.el.

Thanks.

-hume.

[1] https://groups.google.com/forum/#!searchin/clojure/cider/clojure/JfS7ZzePtA4/ZAPHHn1zS5gJ Tim Visher: "Also, Cider is _unstable_ at this point. I'm still using nrepl 0.2.0 and it's working fine. I would _not_ recommend upgrading to Cider at this point."

[2] https://groups.google.com/forum/#!forum/cider-emacs  

[Phillip Lord]

I have tried it a couple of times and keep reverting back to nrepl. One
of the biggest issues is nrepl-ritz which depends on nrepl and not
nrepl-client. So switching to cider appears to mean ditching ritz.

Name changes always cause a significant amount of distruption. I
understand the rationale but only a short time after the slime/swank
split it's a little unwelcome. Especially as I have code
(https://github.com/phillord/tawny-owl/blob/master/emacs/tawny-mode.el)
that I use daily and which depends on nrepl.

Phil

> --

--
Phillip Lord, Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk
School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower, skype: russet_apples
Newcastle University, twitter: phillord
NE1 7RU

[Norman Richards]

On Tue, Nov 12, 2013 at 10:22 AM, Phillip Lord <philli...@newcastle.ac.uk> wrote:

I have tried it a couple of times and keep reverting back to nrepl. One
of the biggest issues is nrepl-ritz which depends on nrepl and not
nrepl-client. So switching to cider appears to mean ditching ritz.

Although I don't understand why anyone thought it was a good idea to change package names, I can confirm that for my daily clojure development, the transition was fairly painless (uninstall/reinstall packages and update some init.el configuration) and has not caused any problems with the set of emacs clojure tools I use.  (which does not include ritz)  I don't remember when I made the move, but it's been at least a week.

[Gary Trakhman]

Stable for me, the only outside tool I use that relies on it is ac-nrepl, but switching the hooks over for cider was painless.

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Tim Visher]

While I'm glad to hear that there are users out there for whom cider
is working great, I would still say based on following the project on
GitHub that there are far too many issues being filed based on
function names not being defined etc. to consider the current release
stable.

As always, YMMV.

[Phillip Lord]

Norman Richards <o...@nostacktrace.com> writes:

> On Tue, Nov 12, 2013 at 10:22 AM, Phillip Lord <philli...@newcastle.ac.uk
>> wrote:
>>
>> I have tried it a couple of times and keep reverting back to nrepl. One
>> of the biggest issues is nrepl-ritz which depends on nrepl and not
>> nrepl-client. So switching to cider appears to mean ditching ritz.
>
>
> Although I don't understand why anyone thought it was a good idea to change
> package names,

The discussion is here:

https://github.com/clojure-emacs/cider/issues/375

Basically, there was lots of confusion between nrepl.el (the client) and
nREPL (the server). Added to switch nrepl.el had lots of functionality
which wasn't just the client -- all of that's in nrepl-client.el now.

Probably a long term win, but a bit of a pain in the short term.

Phil

[Phillip Lord]

I discovered one of the reasons for my issues with stability yesterday.
The version of clojure-test-mode on marmalade still depends on nrepl
(rather than cider), so, despite my best efforts to remove nrepl.el it
was still getting pulled back in.

Fun and games!

Phil

[Colin Yates]

That's the culprit - I was wondering why nrepl wouldn't disappear!

For me, cider has been rock solid with midje-mode, but I am not really exercising it too much.

[Phillip Lord]

I don't normally use test-mode as it happens -- my main library fails to
test correctly in test-mode while working when run through lein for
reasons that I have never determined. Clean tests feel nicer anyway.

I'm hoping ritz updates soon -- name changes have to happen sometimes,
and making the fall out as short as possible has to be a good thing!

Now to fix my own nrepl dependencies!

Colin Yates <colin...@gmail.com> writes:

> That's the culprit - I was wondering why nrepl wouldn't disappear!
>
> For me, cider has been rock solid with midje-mode, but I am not really
> exercising it too much.
>
> On Tuesday, November 19, 2013 2:56:05 PM UTC, Phillip Lord wrote:
>>
>>
>> I discovered one of the reasons for my issues with stability yesterday.
>> The version of clojure-test-mode on marmalade still depends on nrepl
>> (rather than cider), so, despite my best efforts to remove nrepl.el it
>> was still getting pulled back in.
>>
>> Fun and games!
>>
>> Phil
>>

[Bozhidar Batsov]

On Tuesday, November 12, 2013 5:10:43 PM UTC+2, John Hume wrote:

The last (non-authoritative) word on cider on this mailing list[1] was that it is unstable. Is that really the case? Is it just a matter of many packages that depend on it not being updated?

I'm cider's primary maintainer. My opinion is that it's very stable at the moment. More stable and less buggy than nrepl.el ever was. Most packages that used to depend on nrepl.el, now depend on cider. nrepl-ritz is only notable exception.

 

I tried checking the official mailing list[2] and was surprised to find that it's private.

That was an accidental mistake (it seems google groups are private by default).

[Bozhidar Batsov]

On Wednesday, November 13, 2013 1:50:32 AM UTC+2, Tim Visher wrote:

While I'm glad to hear that there are users out there for whom cider
is working great, I would still say based on following the project on
GitHub that there are far too many issues being filed based on
function names not being defined etc. to consider the current release
stable.

I'm fairly certain that those problems are behind us now.

[Bozhidar Batsov]

On Tuesday, November 19, 2013 4:56:05 PM UTC+2, Phillip Lord wrote:

I discovered one of the reasons for my issues with stability yesterday.
The version of clojure-test-mode on marmalade still depends on nrepl
(rather than cider), so, despite my best efforts to remove nrepl.el it
was still getting pulled back in.

Marmalade is a huge problem these days - frequent outages, not to mention many package uploads (including cider 0.4) got corrupted and Nic hasn't been able to figure out what's going on there.

I'd suggest to everyone to use MELPA for the time being.

[Adrian Mowat]

Is cider just a new release of nrepl.el or a different thing entirely?

Sorry to be a noob, but this is awfully confusing to the uninitiated.

[Bozhidar Batsov]

nrepl.el was renamed to cider after version 0.2. You should be using cider :-)

-- 

Cheers,

Bozhidar

On Friday, December 13, 2013 at 9:43 AM, Adrian Mowat wrote:

Is cider just a new release of nrepl.el or a different thing entirely?

Sorry to be a noob, but this is awfully confusing to the uninitiated.

--

--

You received this message because you are subscribed to the Google

Groups "Clojure" group.

To post to this group, send email to clo...@googlegroups.com

Note that posts from new members are moderated - please be patient with your first post.

To unsubscribe from this group, send email to

clojure+u...@googlegroups.com

For more options, visit this group at

http://groups.google.com/group/clojure?hl=en

---

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/LTQd2zmy-MY/unsubscribe.

To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Phillip Lord]

Bozhidar Batsov <bozhida...@gmail.com> writes:
> On Tuesday, November 19, 2013 4:56:05 PM UTC+2, Phillip Lord wrote:
>>
>>
>> I discovered one of the reasons for my issues with stability yesterday.
>> The version of clojure-test-mode on marmalade still depends on nrepl
>> (rather than cider), so, despite my best efforts to remove nrepl.el it
>> was still getting pulled back in.
>>
>
> Marmalade is a huge problem these days - frequent outages, not to mention
> many package uploads (including cider 0.4) got corrupted and Nic hasn't
> been able to figure out what's going on there.
> I'd suggest to everyone to use MELPA for the time being.

So, I have used MELPA before, but I found living on the bleeding edge
for all of my packages is bit painful; the overall stability of my Emacs
setup dropped considerably. I fear this will remain while many package
developers use a "dirty head" versioning system (myself included).

I don't mind doing this for one or two packages where I want bleeding
edge, but I haven't worked out how to get package.el to pick packages
from different repos.

I agree with you about problems with marmalade. What we need is a way
for devs to specify the latest stable version (by commit, branch or tag)
in their Emacs packages. That would mean that, like marmalade, the
developer would control which version is considered stable, but could do
so purely with their VC. Wordpress plugins use something similar.

Phil

[Tim Visher]

Hi Phil,

On Fri, Dec 13, 2013 at 4:57 AM, Phillip Lord
<philli...@newcastle.ac.uk> wrote:
> Bozhidar Batsov <bozhida...@gmail.com> writes:
>> On Tuesday, November 19, 2013 4:56:05 PM UTC+2, Phillip Lord wrote:
>>> I discovered one of the reasons for my issues with stability yesterday.
>>> The version of clojure-test-mode on marmalade still depends on nrepl
>>> (rather than cider), so, despite my best efforts to remove nrepl.el it
>>> was still getting pulled back in.
>>
>> Marmalade is a huge problem these days - frequent outages, not to mention
>> many package uploads (including cider 0.4) got corrupted and Nic hasn't
>> been able to figure out what's going on there.
>> I'd suggest to everyone to use MELPA for the time being.
>
> So, I have used MELPA before, but I found living on the bleeding edge
> for all of my packages is bit painful; the overall stability of my Emacs
> setup dropped considerably. I fear this will remain while many package
> developers use a "dirty head" versioning system (myself included).

That has completely been my experience. Continuous Deployment
_requires_ Continuous Integration and pretty much all of the emacs
package developers out there don't have the time to do CI correctly so
Continuous Deployment simply equals lots of pain on the users end as
things get broken accidentally.

> I don't mind doing this for one or two packages where I want bleeding
> edge, but I haven't worked out how to get package.el to pick packages
> from different repos.

You might consider playing with something that I've had in my
incubator file for awhile:
https://github.com/timvisher/.emacs.d/blob/c8fa14315825f722f9995e8dd1e888c6b81321e9/timvisher/timvisher_incubator.el#L16-L28

> I agree with you about problems with marmalade. What we need is a way
> for devs to specify the latest stable version (by commit, branch or tag)
> in their Emacs packages. That would mean that, like marmalade, the
> developer would control which version is considered stable, but could do
> so purely with their VC. Wordpress plugins use something similar.

I assume you mean something over and above the `Version` ELPA header?
Obviously, that depends on package maintainers following things like
SNAPSHOT versioning (which ELPA doesn't accept) or Semantic Versioning
to tip people off as to what is considered stable.

I think the general attitude I'm seeing amongst some of the package
maintainers out there is that the idea of versioning is a farse
because they always intend to maintain stable HEADs so HEAD is as
stable as your ever going to get. That's a shame, but I get the
sentiment.

So the responsibility for deciding what is stable or not falls to us,
the package users. That's, unfortunately, an area where ELPA is
woefully inadequate at this time. We have no way of specifying that we
want a particular version of a package. That's a basic requirement of
any true dependency management system and for whatever reason the
Emacs devs did not deign to include it yet. I, at this point, would be
fine with specifying a version _or_ commit depending on what package
repo I'm pointing at.

Didn't realize I'd rant this morning. :(

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

[Cedric Greevey]

On Fri, Dec 13, 2013 at 2:43 AM, Adrian Mowat <adrian...@gmail.com> wrote:

Is cider just a new release of nrepl.el or a different thing entirely?

The former.

Sorry to be a noob, but this is awfully confusing to the uninitiated.

Of course it is -- it's emacs.

[Sean Corfield]

On Thu, Dec 12, 2013 at 11:43 PM, Adrian Mowat <adrian...@gmail.com> wrote:
> Is cider just a new release of nrepl.el or a different thing entirely?

Well, it's a "new release" insofar as it's an updated version of
nrepl.el. In order to switch to it, however, you have to remove
nrepl.el _and all packages that depend on it_ (which packages are not
specified in the upgrade instructions so that would be a hit'n'miss
process), then you install cider.el and then you also have to update
various parts of .emac.d/init.el depending on how you had customized
nrepl. And that part isn't really described in the upgrade
instructions either so that's also pretty hit'n'miss. And then you
have to reinstall newer versions of the packages you deleted that
depended on nrepl.el and hope you get versions that depend on cider.el
instead (since there's no way of telling, based solely on their
package description I suspect).

And if you use Ritz, that hasn't been updated so you have to stay with
nrepl.el anyway.

Frankly, I think it was a mistake to rename it and rename various
functions in it, forcing breakage on dependent packages (which have
not changed their names as far as I can tell).

I use ac-nrepl and the latest version still says it is for nrepl so
I've no idea whether it will work with cider. I also use nrepl-ritz
but I could live without it. My nrepl-related init.el file contains:

https://www.refheap.com/21729

and it's not clear how that would need changing and whether it would
continue to work properly.

And this isn't just for me - my team all has the same base
configuration of Emacs and so we'd have to go thru this switch process
for each team member.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Bozhidar Batsov]

On Friday, December 13, 2013 at 7:17 PM, Sean Corfield wrote:

On Thu, Dec 12, 2013 at 11:43 PM, Adrian Mowat <adrian...@gmail.com> wrote:

Is cider just a new release of nrepl.el or a different thing entirely?

Well, it's a "new release" insofar as it's an updated version of

nrepl.el. In order to switch to it, however, you have to remove

nrepl.el _and all packages that depend on it_ (which packages are not

specified in the upgrade instructions so that would be a hit'n'miss

process)

If someone is not clear it should be improved. I can’t know what problems people encounter is they don’t tell me. cider has both an issue tracker and it’s own mailing list. 

, then you install cider.el and then you also have to update

various parts of .emac.d/init.el depending on how you had customized

nrepl. And that part isn't really described in the upgrade

instructions either so that's also pretty hit'n'miss.

All configuration options are documented in the README, so I’d say updating the init.el is an easy task.

 

And then you

have to reinstall newer versions of the packages you deleted that

depended on nrepl.el and hope you get versions that depend on cider.el

instead (since there's no way of telling, based solely on their

package description I suspect).

The list of package dependencies is more informative than a package's name.

 

And if you use Ritz, that hasn't been updated so you have to stay with

nrepl.el anyway.

Frankly, I think it was a mistake to rename it and rename various

functions in it, forcing breakage on dependent packages (which have

not changed their names as far as I can tell).

You’re thinking short term, but you should be thinking long term. Nobody will remember this transition is a few months. I’m confident that in the greater scheme of things the rename was a good solution. 

 

I use ac-nrepl and the latest version still says it is for nrepl so

I've no idea whether it will work with cider. I also use nrepl-ritz

ac-nrepl supports only cider. 

 

but I could live without it. My nrepl-related init.el file contains:

https://www.refheap.com/21729

and it's not clear how that would need changing and whether it would

continue to work properly.

Your eval-in-repl function is obsolete, since similar functionality lives in cider itself. 

I have no idea why you’re modifying clojure-mode’s keymap when you should be modifying cider-mode’s keymap instead (+ set-ns is bound to a keycombo by default). Consulting the Changelog would reveal that `nrepl-mode` is now named `cider-repl-mode` and `nrepl-interaction-mode` is now `cider-mode` (it’s basically the same in SLIME). The migration is really simple and I think that people are blowing this problem out of proportion. Of course, I basically live in Emacs, so this is obviously affecting my POV. Less experienced Emacs users might find even simple changes challenging.  

And this isn't just for me - my team all has the same base

configuration of Emacs and so we'd have to go thru this switch process

for each team member.

As I said previously - if you’re not certain about something you should stop by either cider’s google group or the GitHub project. :-)

 

--

Sean A Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."

-- Gustave Flaubert, French realist novelist (1821-1880)

[Rostislav Svoboda]

> I can’t know what problems people encounter is they don’t tell me.

You may ask somebody to test your changes before you publish them.
Pardon me in case you did so. It seems like people were not listening.
Anyway you should be prepared for this eventuality too and have an
undo-scenario.

Bost

[Phillip Lord]

Tim Visher <tim.v...@gmail.com> writes:
>> So, I have used MELPA before, but I found living on the bleeding edge
>> for all of my packages is bit painful; the overall stability of my Emacs
>> setup dropped considerably. I fear this will remain while many package
>> developers use a "dirty head" versioning system (myself included).
>
> That has completely been my experience. Continuous Deployment
> _requires_ Continuous Integration and pretty much all of the emacs
> package developers out there don't have the time to do CI correctly so
> Continuous Deployment simply equals lots of pain on the users end as
> things get broken accidentally.

I am not sure that I would say this. Pulling stuff out of people's repos
without an understanding of how they use the repo is, I think, the
problem.

>
>> I don't mind doing this for one or two packages where I want bleeding
>> edge, but I haven't worked out how to get package.el to pick packages
>> from different repos.
>
> You might consider playing with something that I've had in my
> incubator file for awhile:
> https://github.com/timvisher/.emacs.d/blob/c8fa14315825f722f9995e8dd1e888c6b81321e9/timvisher/timvisher_incubator.el#L16-L28
>

Yeah, that's interesting, although I would be worried about getting
duplicates of dependencies.

>> I agree with you about problems with marmalade. What we need is a way
>> for devs to specify the latest stable version (by commit, branch or tag)
>> in their Emacs packages. That would mean that, like marmalade, the
>> developer would control which version is considered stable, but could do
>> so purely with their VC. Wordpress plugins use something similar.
>
> I assume you mean something over and above the `Version` ELPA header?
> Obviously, that depends on package maintainers following things like
> SNAPSHOT versioning (which ELPA doesn't accept) or Semantic Versioning
> to tip people off as to what is considered stable.

So, the way wordpress use their subversion is that head is dirty, and
that tags are stable (not a bad way to do things!).

At the same time, though, you put a stable tag into your file. Now, with
"Version" it means "the current version", so when you have a dirty head
this will point either to a snap version or the next version. With the
wordpress approach you know where the head is (because it's, er, the
head) and you know what the last stable version was (because you look at
the head, and it tells you).

> I think the general attitude I'm seeing amongst some of the package
> maintainers out there is that the idea of versioning is a farse
> because they always intend to maintain stable HEADs so HEAD is as
> stable as your ever going to get. That's a shame, but I get the
> sentiment.

For me, I maintain the sentiment that my version control system is,
well, mine. I use it to support my development. I am happy to use it as
a distribution system so long as that does not interfere.

Github generates releases from tag information. This isn't a bad
technique, but works on a repo basis while I maintain all of my emacs in
one repo.

Phil

[Gary Johnson]

Just to inject another sample into the population:

As another hacker who lives in Emacs, I found the nrepl -> cider transition to be quite painless. It took me maybe an hour of reading the website docs, installing/uninstalling packages with package.el, and updating the relevant sections of my .emacs.d/init.el file. Not to poo-poo on anyone's parade, but it really did seem pretty straightforward to me. So maybe some of the pain points people are feeling have to do with general challenges with configuring Emacs rather than specific problems with following the online cider docs.

As a final note, ac-nrepl is documented on the cider page as working with cider. The nrepl-ritz package incompatibility is the only real issue missing from the docs. On the other hand, it's come up repeatedly on this mailing list, so at least some of us are likely to be aware of it at this point.

  ~Gary

[Cedric Greevey]

On Mon, Dec 16, 2013 at 12:27 PM, Gary Johnson <gwjo...@uvm.edu> wrote:

Just to inject another sample into the population:

As another hacker who lives in Emacs, I found the nrepl -> cider transition to be quite painless. It took me maybe an hour of reading the website docs, installing/uninstalling packages with package.el, and updating the relevant sections of my .emacs.d/init.el file. Not to poo-poo on anyone's parade, but it really did seem pretty straightforward to me.

Interesting, isn't it, what emacs users consider to be "quite painless". Users of non-legacy tools tend to set the bar rather higher, needless to say, typically expecting upgrading something (other than the operating system itself) to take a few minutes, tops, with most of that spent doing something else while progress meters (first "downloading", then "installing") crawl to 100% and the result working OOTB without manual config changes or other nursemaiding.

 

So maybe some of the pain points people are feeling have to do with general challenges with configuring Emacs rather than specific problems with following the online cider docs.

That much is quite believable. :)

[n aipmoro]

On Mon, Dec 16, 2013 at 12:27 PM, Gary Johnson <gwjo...@uvm.edu> wrote:

 

It took me maybe an hour of reading the website docs, installing/uninstalling packages with package.el, and updating the relevant sections of my .emacs.d/init.el file. Not to poo-poo on anyone's parade, but it really did seem pretty straightforward to me.

 

I thought I read the website docs thoroughly, I thought I uninstalled the proper packages
and I thought I edited my .emacs file correctly. But the repl refused to start-up so I returned

to nrepl. I am not even remotely an emacs expert, but until this incident I had years of

trouble-free emacs/leningen/nrepl/slime/swank use.

regards,

naipmoro

[Phillip Lord]

Gary Johnson <gwjo...@uvm.edu> writes:
> As another hacker who lives in Emacs, I found the nrepl -> cider transition
> to be quite painless. It took me maybe an hour of reading the website docs,
> installing/uninstalling packages with package.el, and updating the relevant
> sections of my .emacs.d/init.el file.

Well, it's an interesting opinion, but in to my mind, "an hour of
reading and updating" != "relatively painless".

> Not to poo-poo on anyone's parade, but it really did seem pretty
> straightforward to me.

I also had to port my own nrepl dependencies. Only of the unfortunate
things about Emacs is that hook name changes don't get picked up
automatically.

Still, pain in the ass though it was, hopefully, it should be over. I
think changing the name to distinguish between the protocol and the
environment is no bad thing, even if it was hard work.

Phil

[Bozhidar Batsov]

Good news for the Marmalade users here!

Nic Ferrier has fixed the package upload problem that plagued cider 0.4 and it’s now available for installation from there.

-- 

Cheers,

Bozhidar