Fork me on GitHub
#boot
<
2018-03-22
>
seancorfield01:03:34

@cfleming How's Cursive support for deps.edn these days?

seancorfield01:03:31

Encouraging Boot users to migrate to deps.edn and use boot-tools-deps for other stuff on top seems like a potentially viable path for Cursive (given Boot's completely dynamic approach to build dependencies otherwise).

donaldball03:03:52

Is anyone working on reducing the variance between boot-tools-deps and the clojure deps tools?

cfleming03:03:37

@seancorfield Still absent, but I’m planning to add that first for exactly that reason. It won’t make arbitrary boot projects more usable in Cursive, but it will at least give boot users a way to make their projects more Cursive-friendly.

seancorfield03:03:26

@donaldball As the maintainer of boot-tools-deps I'd be interested to here what variance you'd like reduced?

seancorfield16:03:50

@donaldball bumping this in case you didn't see it last night...

donaldball16:03:57

Oh, hah, sorry! I’d been laboring under the misimpression that boot-tools-deps didn’t support git dependencies, though I don’t see that called out in fact.

seancorfield17:03:12

From the Changes section of the README: > 0.2.0 -- 01/28/2018 -- Update to use the most recent tools.deps.alpha release; directly update the Boot classpath (which means Git and Local dependencies are now supported!); run tools.deps inside a Boot pod; no longer update Boot's :dependencies by default.

donaldball19:03:22

\o/ I withdraw my foolish query

seancorfield19:03:10

Seriously tho', if anything bothers you about boot-tools-deps, bring it up with me or open a GitHub issue -- I want it to be the best Boot + deps tooling it possibly can be.

seancorfield03:03:48

@cfleming Good to know. Thanks Colin!

seancorfield03:03:22

@donaldball boot-tools-deps uses tools.deps.alpha directly to produce the classpath so anything you do purely based on the classpath ought to have zero variance. The difficulties arise when you need to shoehorn that into Boot's model of :resource-paths, :source-paths, and :dependencies -- which is what the -B and -Q options are for...

cfleming05:03:09

@seancorfield How does boot-tools-deps work with git deps?

cfleming06:03:16

@seancorfield Actually, thinking about it, never mind - from Cursive’s point of view these projects would just be deps projects, and I’ll integrate with that directly.

shakdwipeea15:03:19

I am trying to connect to a clojure repl running in vagrant from host machine. I am getting this error:

SocketException The transport's socket appears to have lost its connection to the nREPL server
        clojure.tools.nrepl.transport/bencode/fn--2017/fn--2018 (transport.clj:95)
        clojure.tools.nrepl.transport/bencode/fn--2017 (transport.clj:95)
        clojure.tools.nrepl.transport/fn-transport/fn--1989 (transport.clj:42)
        clojure.core/binding-conveyor-fn/fn--5476 (core.clj:2022)
        java.util.concurrent.FutureTask.run (:-1)
        java.util.concurrent.ThreadPoolExecutor.runWorker (:-1)
        java.util.concurrent.ThreadPoolExecutor$Worker.run (:-1)
        java.lang.Thread.run (:-1)
The boot task I am using is
(deftask dev
  "Run a restartable system in the Repl"
  []
  (comp
   (environ :env {:http-port "9000"})
   (watch :verbose true)
   (system :sys #'base-system :auto true :files ["handler.clj" "html.clj"
                                                 "pipeline.clj" "steps.clj"])
   (repl :server true
         :host "0.0.0.0"
         :port 62000)))
I have tried with the host key and w/o to no luck. I have forwarded the relevant ports in the vagrantfile
config.vm.network "forwarded_port", guest: 9000, host: 9000
  config.vm.network "forwarded_port", guest: 62000, host: 62000
I am able to see the server at port 9000 but not able to connect to the repl.

shakdwipeea15:03:12

I can see that nrepl is successfully started

Starting #'airplanes.systems/base-system
nREPL server started on port 62000 on host 127.0.0.1 - 
Elapsed time: 2.871 sec

shakdwipeea15:03:05

What are the things that I can try to resolve this ?

seancorfield16:03:01

@cfleming boot-tools-deps defers to tools.deps.alpha to build the classpath -- complete with downloading/unpacking/analyzing any git deps, or local deps, along with any other deps.edn stuff -- and it then uses that classpath for subsequent operations in the task pipeline. Some Boot tasks only work from :resource-paths, :source-paths, and/or :dependencies, so boot-tools-deps provides options to overwrite all of those from what it finds on the classpath (`-B`) or merge the classpath into those (`-Q`). It puts :paths from deps on :resource-paths, :extra-paths from deps on :source-paths, all JARs into :dependencies (based on the library list that deps figures out), and any folders from the deps (the local and git deps) into :source-paths. It's not a perfectly 1:1 mapping from deps to Boot but it's close enough (via overwrite or merge) to work for nearly all tasks.

seancorfield16:03:33

@shakdwipeea Perhaps something else is trying to use port 62000 -- maybe try a different port, like 50505 or even 5555?

shakdwipeea16:03:34

@seancorfield tried that, it gives back the same error.

shakdwipeea16:03:42

One thing I noticed was, even if in my task I specify the host to be "0.0.0.0", the nREPL server is still started on <nrepl://127.0.0.1:<port>> . Is this expected ?

shakdwipeea16:03:43

Solved it. The trick was to set the :bind key to "0.0.0.0" and not the host.

(repl :server true
         :bind "0.0.0.0"
         :port 50505)
This works.

seancorfield16:03:35

Ah, I hadn't even noticed that. Sorry. Glad you got it working!

👍 4