Dependency on cider in 0.3.0-SNAPSHOT ?

[rundis]

Hi !

First of all thx for a great lib and super initiative. @magnars demonstrated some cool refactoring stuff in Emacs and through that I discovered this lib. I'm currently working on utilizing some of the features from this for adding clojure refactoring support to Light Table :)

Anyways, I've managed to get some stuff working using the 0.2.2 version. However the readme documents some features that aren't part of 0.2.2 so I hoped I might be able to try them out by using the snapshot version. However it seems to croak.

I just added :plugins [[refactor-nrepl "0.3.0-SNAPSHOT"]] to my ~/.lein/profiles.clj and then tried to do lein repl on a project. And I got the below.

Maybe there has been introduced an (implicit) dependency on cider ?

Error loading refactor-nrepl.ns.clean-ns: java.io.FileNotFoundException: Could not locate cider/nrepl/middleware/info__init.class or cider/nrepl/middleware/info.clj on classpath: , compiling:(refactor_nrepl/ns/dependencies.clj:1:1)
Exception in thread "main" java.lang.RuntimeException: Unable to resolve var: refactor-nrepl.ns.clean-ns/wrap-clean-ns in this context, compiling:(/private/var/folders/c7/_w_4f1617dvbdkcx17ppnpfw0000gn/T/form-init7033284104408479432.clj:1:2749)
    at clojure.lang.Compiler.analyzeSeq(Compiler.java:6651)
    at clojure.lang.Compiler.analyze(Compiler.java:6445)
    at clojure.lang.Compiler.analyze(Compiler.java:6406)
    at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3719)
    at clojure.lang.Compiler.analyzeSeq(Compiler.java:6646)
    at clojure.lang.Compiler.analyze(Compiler.java:6445)
    at clojure.lang.Compiler.analyze(Compiler.java:6406)
    at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3719)
    at clojure.lang.Compiler.analyzeSeq(Compiler.java:6646)
    at clojure.lang.Compiler.analyze(Compiler.java:6445)
    at clojure.lang.Compiler.access$100(Compiler.java:38)
    at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6050)
    at clojure.lang.Compiler.analyzeSeq(Compiler.java:6644)
    at clojure.lang.Compiler.analyze(Compiler.java:6445)
    at clojure.lang.Compiler.analyze(Compiler.java:6406)
    at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5782)
    at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5217)
    at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3846)
    at clojure.lang.Compiler.analyzeSeq(Compiler.java:6642)
    at clojure.lang.Compiler.analyze(Compiler.java:6445)
    at clojure.lang.Compiler.eval(Compiler.java:6700)
    at clojure.lang.Compiler.eval(Compiler.java:6693)
    at clojure.lang.Compiler.eval(Compiler.java:6693)
    at clojure.lang.Compiler.load(Compiler.java:7130)
    at clojure.lang.Compiler.loadFile(Compiler.java:7086)
    at clojure.main$load_script.invoke(main.clj:274)
    at clojure.main$init_opt.invoke(main.clj:279)
    at clojure.main$initialize.invoke(main.clj:307)
    at clojure.main$null_opt.invoke(main.clj:342)
    at clojure.main$main.doInvoke(main.clj:420)
    at clojure.lang.RestFn.invoke(RestFn.java:421)
    at clojure.lang.Var.invoke(Var.java:383)
    at clojure.lang.AFn.applyToHelper(AFn.java:156)
    at clojure.lang.Var.applyTo(Var.java:700)
    at clojure.main.main(main.java:37)
Caused by: java.lang.RuntimeException: Unable to resolve var: refactor-nrepl.ns.clean-ns/wrap-clean-ns in this context
    at clojure.lang.Util.runtimeException(Util.java:221)
    at clojure.lang.Compiler$TheVarExpr$Parser.parse(Compiler.java:659)
    at clojure.lang.Compiler.analyzeSeq(Compiler.java:6644)
    ... 34 more

[benedekfazekas]

hi Magnus,

indeed we depend on cider-nrepl, see our project.clj. Also see the discussion on this commit about adding this dependency: https://github.com/clojure-emacs/refactor-nrepl/commit/a57b6f7dc052abeb19c2b705044256348b9e0e78

just out of curiosity: is your plan to use the refactor-nrepl middleware in a lighttable/a lighttable plugin or you rather interested in refactor ideas?

is adding the cider middleware to your profiles.clj a blocker for your work? tbh we have one feature depending on one cider function, so eliminating this dependency should not be too difficult.

[rundis]

Hi Benedek !

The plan was to to create a Light Table plugin (ref https://github.com/rundis/clj-light-refactor) that uses the refactor-nrepl middleware to enable some of its features akin to clj-refactor.el. Actually I've already made some progress with artifacts and find usages.

Just tested with adding cider as a plugin dep to my profiles.clj and ssems to work ok. If it's just a matter of adding another precondition to the cider nrepl plugin, it's no showstopper at all. In principle though It would be nice to have as few dependencies as possible. However if it enables adding cool valuable features and still lives up to nREPL middleware to support refactorings in an editor agnostic way. who am I to complain :-)

Anyways you now have a non-emacs user of your lib !

BTW: Do you have a schedule for a 0.3.0 release ? If it's not to far off, I might release/launch my plugin once it has been tried and tested

[benedekfazekas]

Anyways you now have a non-emacs user of your lib !

nice! :dancers:

It would be nice to have as few dependencies as possible

yeah, well. absolutely. there is lot of discussion and work around refactor-nrepl to have the good things from both worlds: freely adding dependencies but avoid the non desired side effects of this on the users. one of these is my bastard son mranderson but we also experimenting with more proper solutions, see #20.

On the other hand tho I think @bbatsov and friends created the cider-nrepl middleware with the same 'editor agnostic' approach in mind: so in fact with adding the cider middleware you unlock a bunch of features which might be useful for your plugin.

BTW: Do you have a schedule for a 0.3.0 release ? If it's not to far off, I might release/launch my plugin once it has been tried and tested

just pinged @magnars and @expez yesterday about this: clj-refactor 1.0 release is really close to the door now and most likely we will release refactor-nrepl in sync with it -- perhaps even the version numbers will match ;)

[bbatsov]

@rundis Yeah, despite the name there's pretty much nothing CIDER-specific in cider-nrepl. vim-fireplace uses it internally, and I'd love to see more editors doing so. I recall LT had some nREPL middleware of its own, but haven't really used LT that much, so I'm not very familiar with its inner workings.

I think that when we one day find a bullet-proof way to isolate middleware deps the two middleware collections might be merged into one, which will provide everything you need to implement great Clojure support in editor X.

[expez]

There's quite a bit of cool stuff in cider-nrepl so if LT hasn't already re-implemented that stuff you might consider exposing some of that functionality too.

I added cider-nrepl with scope set to provided so we didn't pull in another version of cider for our users, but I suppose we might reconsider that now.

I want the 0.9-SNAPSHOT of CIDER but if we formally depend on 0.8.2 won't we get into a classloader race where either one of those versions could be the one actually in use? Afaik it's up to the jvm implementation which class it actually loads to resolve such conflicts.

[rundis]

I got one unfortunate side effect of pulling in the cider dependency. Seems to be that it breaks my figwheel setup (probably due to a dependency conflict). Ref https://github.com/bhauman/lein-figwheel/issues/71

[rundis]

Sorry my bad. I guess it's actually the dependency on http-kit used in 0.3.0-SNAPSHOT that is causing it. (I'm using an older version of figwheel than the one referenced in the issue above

[benedekfazekas]

is it cider tho? I guess this is refactor-nrepl's hotload dependency biting us again. that depends on pomegranate which depends on a really old version of commons.http that is the culprit i think...

that said hotload dependency is really cool. i use it frequently... but we might want to consider removing it temporarily until we solve the classloading isolation problem... @expez what do you think?

[benedekfazekas]

ok got a bit confused I guess, sry ;) have not read the referenced issue properly... pls ignore previous. so do we clash on http-kit version with figwheel then?

[rundis]

Haven't dug into the details. I get a "No matching ctor found for class org.httpkit.server.HttpServer"

Removing the 0.3.0-SNAPSHOT dependency of refactor-nrepl from my profiles.clj makes figwheel work again. When I get some more time I'll try and look into transitive dependency hell conflict resolution mode :)

[bbatsov]

that said hotload dependency is really cool. i use it frequently... but we might want to consider removing it temporarily until we solve the classloading isolation problem... @expez what do you think?

I'd remove it - depending on pomegranate was problematic for cider in the past (that's why we removed it).

[expez]

I'll leave the cider dependency with scope :provided for now because I don't want us to override whatever version the user prefers.

The dependence on pomegranate is gone. We're now depending on alembic which delegates to pomgranate but does so in an isolated classloader.

[rundis]

I still can't use 0.3.0-SNAPSHOT (-23) with figwheel. I'll see if upgrading figwheel helps.

java.lang.IllegalArgumentException: No matching ctor found for class org.httpkit.server.HttpServer, compiling:(org/httpkit/server.clj:23:11)

[expez]

damn, aight then this will get solved by #20 :(

[benedekfazekas]

i am sure i am missing something here. in refactor-nrepl we use http-kit 2.1.19 while on the github page 2.1.18 is advertised... how come we use a fresher version than the one in project.clj?!

[expez]

The readme is out of date. It's available on clojars. This is another reason to use add-project-dependency :p

[benedekfazekas]

figwheel seems to be a bit behind: https://github.com/bhauman/lein-figwheel/blob/master/sidecar/project.clj @rundis: you can always do a PR there too ;)

[rundis]

Hehe sure. Well It seems my current project is way behind (using 0.1.7 of figwheel). Upgrading was not a trivial task it seems (aka failed miserably)