Namespace migration

[cemerick]

As a consequence of #1, it seems necessary to eventually move nREPL out of the clojure.tools.nrepl.* namespaces associated with Clojure Contrib. After all, tools.nrepl may yet be maintained separately from this effort, and no one benefits from same-named namespaces floating around in multiple artifacts.

I see two options:

1. Cut over to cemerick.nrepl.* namespaces, and stop distributing clojure.tools.nrepl.*-namespaced code from here ASAP.
2. Move the actual code to cemerick.nrepl.* namespaces, replacing the clojure.tools.nrepl.* namespaces with stubs that use immigrate or similar to ensure API compatibility for downstream tools and libraries. This arrangement can persist for some period of time, eventually moving those stubs into a separate "nrepl-compat" library, that can be added in downstream as needed to provide those clojure.tools.nrepl.* namespaces.

Thoughts?

[cemerick]

Let me know what you think, @technomancy, @bbatsov, @trptcolin, @cursive-ide?

[cursive-ide]

I think that option 1 should be fine as long as the wire protocol hasn't changed. That means that the client and server can be upgraded independently, and I don't really see much benefit to keeping them around if the new namespaces are equivalent and it's just a matter of renaming them.

It's been a while, but I don't think there's anything like namespaced keywords or anything else where the nREPL namespaces would leak into the protocol, right?

[trptcolin]

Agreed on option 1.

At first I was thinking the only issues I’d foresee w/ option 1 would be if anybody’s got themselves into a non-repeatable situation w/ version ranges or something like that? But this would be a brand new group/artifact pair anyway, so I don’t see any risk of breakage. And even if it wasn’t, there’s less risk than elsewhere because nrepl is pretty high-level and we’re unlikely to see many transitive dependencies around it.

@cemerick did you have thoughts on arguments in favor of option 2? I guess maybe it saves coordination work for cases like nrepl middleware where you have several libs that need to all depend on the same ns[es]?

[cemerick]

@cursive-ide No, there's no namespaced keywords in use that I'm aware of.

@trptcolin My sole motivation re: option (2) is to make the transition as painless as possible. A quick sed is about as easy as it gets I guess, so maybe I'm agonizing too much. :-P You're right that middleware authors are going to be most hard-hit.

[trptcolin]

@cemerick: well, middleware users are the real interesting piece, i’d think, since they’ll now have to ensure compatibility among N middlewares. Unfortunately i’m not a middleware user so I can’t give much of an informed opinion here.

[cemerick]

Users only ever need to e.g. drop a middleware's var name into their project.clj; it's the authors that might be using org.clojure.*-namespaced vars in their middleware descriptors. Or am I missing something?

[trptcolin]

I’m sure @bbatsov has a clearer picture, but i’m talking about dependency versions: if as an end user I have in my profiles.clj (or wherever) e.g.

:plugins [[refactor-nrepl "2.3.1"]
          [cider/cider-nrepl "0.14.0"]]

Then I need to ensure those all line up and are compatible w/ my nrepl variant, including any bumps to lein/boot version.

[bbatsov]

Cut over to cemerick.nrepl.* namespaces, and stop distributing clojure.tools.nrepl.*-namespaced code from here ASAP.

That's what I'd advise to do. For me updating our namespaces is going to be trivial. I think the middleware surrounding CIDER + piggieback is probably the bulk of the 3rd party middleware out there and as we have complete control over them the actual migration can happen very fast.

[cemerick]

Well, I guess we have consensus, then.

The plan then: 0.3.0 will contain the clojure.tools.* namespaces as previously discussed on the ML, etc. I think providing a checkpoint release that matches the last tools.nrepl release is important.

The next release (0.4.0, I guess) will switch over namespaces, without any compatibility shims.

Thanks for the feedback 😄

[bbatsov]

All of this makes perfect sense to me! 👍