Fork me on GitHub
#cider
<
2020-03-19
>
solf05:03:43

Is there a way I can have my source code locally and edit it with emacs/cider, yet starting the java process on a remote machine?

jumar06:03:05

@U7S5E44DB look at https://stackoverflow.com/questions/52459671/clojure-how-to-connect-to-running-repl-process-remotely You could use this to start lein repl on the remote machine and then cider-connect:

# on remote machine
lein repl :start :port 40000

# on localhost
ssh -NL 40000:localhost:40000 username@host
# THEN: lein repl :connect OR cider-connet
lein repl :connect localhost:40000

solf06:03:05

In this case then the source code is in the remote machine, right?

jumar06:03:31

Yes, that's right - you need that; but you can reload the code based on local changes

jumar06:03:35

What's your use case?

solf06:03:53

Dev mostly on my laptop, but when doing some intensive computation spin up a remote instance from scratch and start a java process from there (using CIDER)

jumar06:03:39

How are you going to "deploy" the program to the remote machine? Seems like pushing code there could be an option?

solf06:03:30

Yes indeed, I think that's the simplest solution to this, in which what you linked will help

👍 4
solf06:03:09

or an uberjar?

solf06:03:50

I don't know if you can run lein repl using an uberjar instead of source code

orestis08:03:56

If your remote machine has all the dependencies you need, then you don’t actually need to send your own source code. You can just connect to the remote REPL and start evaluating code.

jumar11:03:18

That’s of course the whole point of this exercise; but you need the initial version to run Leon repo, I think

jumar11:03:06

You could also use socket repl with Uber jar but i don’t think cider supports this

aisamu15:03:44

When I used to do this, both tramp (source+repl on the remote instance) and hybrid (local source + forwarded ssh port connected to the remote instance running a repl) worked fine. At the time I had to match the folder structure for "hybrid" to work properly, otherwise cider would try to find the source files using the remote's paths. Now there's a configuration option for that as well.

Eamonn Sullivan12:03:00

I have a small project using tools.cli (deps.edn) to manage dependencies and stuff. Running clj -A:test:runner runs all of my unittests, but I can't convince cider that this project has any. In my leiningen projects, I've gotten to like running C-c , ... to run my tests, but when I try that in cider for this project, I get errors about No test namespace. Maybe I've configured something incorrectly? Does this work for someone else? Can you share a snippet of your deps.edn?

practicalli-johnny12:03:56

@eamonn.sullivan the simplest way is to add test to your paths in deps.edn and you dont need a specific alias, as the test path is always included :paths ["src" "test" "resources"]

Eamonn Sullivan12:03:21

I think I do have that? That's why clj -A:test:runner works, I thought. But my understanding of this is limited. What would I need to add to this?

practicalli-johnny12:03:20

CIDER will not use an alias unless you tell it to use it. The test path is only in an alias

Eamonn Sullivan12:03:21

Or, sorry, I see your paths bit. I missed that. Thanks!

practicalli-johnny12:03:51

Just added it. Ideally, you should add a .dir-locals.el file that defines the alias you want to run

practicalli-johnny12:03:35

Or you can use C-u (or SPC u in Spacemacs) to edit the jack-in command when before it runs and add an alias to the start

Eamonn Sullivan12:03:04

Well, just adding the test to the paths worked a treat. I'll look into .dir-locals.el if I need something more complicated. Thanks again!

practicalli-johnny12:03:43

you could just add a .dir-locals.el to the root of your project with this in it

((clojure-mode . ((cider-clojure-cli-global-options . "-A:test"))))
And then all your test code is included via the alias. CIDER uses its own test runner, so you dont need the :runner alias

👍 4
practicalli-johnny12:03:52

Adding tests to paths may include test code in other tasks, eg. like deployment, so probably the preferred solution long term (but a useful quick hack)