When connecting to shadow-cljs server from Cursive via a "remote" configuration, is it possible to get Cursive to execute some code (eg api/watch and api/nrepl-select)?

@grav Do you mean when the REPL connects? There’s no way in Cursive to do that, but you might be able to use user.clj to do it at the Clojure level? If that doesn’t work let me know, and I can think about adding it to Cursive.

Yes, when the REPL connects. Can you explain what you mean with user.clj?

@cfleming ^

@grav Sure, when a Clojure REPL connects, if there’s a user.clj file at the root of the classpath (i.e. in a src folder, not in a namespace) then it will load that file automatically when it starts.

Do you want that code executed in clj or cljs?

I don’t know if cljs has something similar - #clojurescript could probably tell you.

In clj. It will (as I understand it) launch a cljs repl

Ok, then user.clj should work for you I think.

So I guess user.clj would work. I'll try it!

Great, let me know how it works.

Ok, so shadow-cljs server does execute whatever's in user.clj, but calling the above-mentioned functions causes an exception. If I execute it with a remote REPL connection, it works.

Maybe I should search for a hook in shadow-cljs that can execute the code, whenever a remote repl connection is initiated.

Or you could implement an "evaluate this file after connection" option for remote REPL configurations 🙂

Hehe

The exception is

Exception in thread "main" java.lang.ExceptionInInitializerError
	at clojure.main.<clinit>(main.java:20)
Caused by: clojure.lang.ExceptionInfo: missing instance {}, compiling:(user.clj:4:1)

In general I’m a little reluctant to duplicate functionality that’s in clojure itself, although admittedly user.clj has a discoverability issue since a lot of people ask about this.

Haha, yes. It's a bit magic. But I get your point about duplicate functionality. I could probably ask thheller about a hook in shadow-cljs

I think the first stop would be to investigate the exception - it’s possible that it’s something simple. thheller may have ideas about that too.

Ok. will do! Thanks 🙂

How to change the spacing for hiccup vectors? I know the standard is just one space, but I have difficulties in seeing this amount of space. I tried File->Settings->Editor->Code Style->Clojure but could not find an option to indent vectors (such as the one used by hiccup html code).

@cfleming hey 🙂 I'm just trying to setup cljdoc with Cursive on a friends computer and some resource that should be on the classpath can't be found. Specifically a file that's part of a :local/root dependency: https://github.com/cljdoc/cljdoc/blob/master/deps.edn#L43 We are on the latest EAP release, is this supposed to work and we're doing something wrong?

@martinklepsch Yes, that should work, what are you seeing?

https://github.com/cljdoc/cljdoc/blob/master/modules/shared-utils/src/cljdoc/util.clj#L12 This line is throwing with "Cannot open <nil> as a reader" (i.e. file not found)

This is in a REPL?

We're trying to load the namespace via CMD + Shift + L

Ok, let me clone that and try, one sec

thank you, much appreciated. I'm so clueless about Cursive haha

Your friend is on 1.8.0-eap8 right?

Just waiting while it downloads the internet…

I get this error when syncing the project: “Manifest type not detected when finding deps for cljdoc/shared-utils in coordinate {:local/root “../shared-utils”}”

Did you get that?

I don't think so. What specifically are you referring to with "syncing the project" running clj for the first time?

No, when importing the project into Cursive.

How did you do that?

So that error message comes back from deps, and is of mysterious origin. But what’s weird is that the path is wrong.

Oh wait, it’s actually complaining about analysis-runner, not cljdoc

I fixed that problem by making modules/analysis-runner/deps.edn look like:

{:paths ["src" "resources"]
 :deps {cljdoc/shared-utils {:local/root "../shared-utils"
                             :deps/manifest :deps}}}

I see the problem you’re seeing, and for some reason those paths are coming through as:

/Users/colin/.gradle/caches/modules-2/files-2.1/com.jetbrains.intellij.idea/ideaIC/183.3283.2/f6ecc94209dbdecaea93389221b330c52f8f367d/ideaIC-183.3283.2/bin/modules/analysis-runner/src
/Users/colin/.gradle/caches/modules-2/files-2.1/com.jetbrains.intellij.idea/ideaIC/183.3283.2/f6ecc94209dbdecaea93389221b330c52f8f367d/ideaIC-183.3283.2/bin/modules/analysis-runner/resources

Investigating….

Ok we just tried with the :deps/manifest addition and the issue seems to remain the same but we're not 100% certain we did everything correct. Is there something specific we need to watch out for when launching the REPL process?

(we tried clearing .cpcache FWIW)

@martinklepsch No, this appears to be a large can of worms inside Cursive and tools.deps. I’m not sure exactly what the problem is, but my working theory is that it’s something to do with the CWD because I call tools.deps as a library.

Still investigating…

Ok cool, no rush ✌️

@tmarble I have one, and a debugger 🙂

sweet!

It’s complicated however since IntelliJ starts background processes to do this stuff.

@martinklepsch This is partly a tools.deps bug, and partly a Cursive bug.

Alex says: > Transitive local deps with relative paths are a problem and that’s a known issue

You have that because cljdoc requires modules/analysis-runner, and that requires ../shared-utils.

Interesting. I never ran into that for some weird reason then @cfleming

@martinklepsch https://dev.clojure.org/jira/browse/TDEPS-74

That doesn’t look exactly like what’s happening in Cursive, but I think it’s related.

@martinklepsch https://github.com/cursive-ide/cursive/issues/2065

thanks for digging into this today Colin! Can cursive run the clj process with an alias somehow? I'm thinking of adding an alias with the source paths and dependencies manually added as a workaround

@martinklepsch Yes, you can do that. However it might be tricky if you run into the bug with the initial sync since Cursive has to do that first to know which aliases are available.

If you manage to get past that, then View-&gt;Tool Windows-&gt;Clojure Deps, open the cljdoc project, under Aliases select the aliases you need and then hit refresh.

When starting a REPL you can add the aliases in the REPL Run Configuration page.

ok cool, we'll give that a shot

I see Run with Deps was added to the REPL run config. If I am creating a REPL, shouldn't Cursive ignore my :main-opts for any aliases I specify?

The behavior I am seeing is: I have a :test alias that has :main-opts specified and when I click the Run button to open the REPL, it runs my tests in the REPL window and then exits the process. Nifty, but not what I expected.

@kenny I don’t think so, those are required to e.g. supply -m figwheel.main for a figwheel REPL

Deps does have the concept of separate alias types for things like this, but AFAICT no-one actually uses them and Cursive effectively always passes -A.

Oh I misunderstood. I thought those were for specifying aliases to start a REPL with that differ from the project aliases.

Is that something that will be added before deps support is complete?

You mean support for different alias types?

I’m not sure, I think it’s pretty confusing.

No. I mean I can select the aliases Cursive uses to resolve things in my project by going to the Deps panel and checking the boxes. I may not want to start a REPL using those same aliases though.

@kenny That works now, those aliases are independent.

Oh. How do I do that?

i.e. I want to resolve my project with aliases :test and :dev but only start my REPL with :test.

You choose :test and :dev in the boxes in the toolwindow as always, and when running your REPL choose to run with deps and just put test in the aliases box.

But, that will use :main-opts from that alias.

So that's the problem I started with.

Right, there’s no way to avoid that right now except to split that alias into two I guess.

One part with deps, and one with main-opts

I guess. I'd prefer to not have to make code changes due to tooling though.

I’m afraid that’s the only option right now, if your main opts stop the REPL running and you need the test deps.

It seems like the only real solution is to separate out -R and -A. In practice I don't ever use -R - CI runs tests using -A and Cursive starts the REPL with aliases and ignores :main-opts. But it makes sense for the case.

Sure. I spoke to Alex about it and he didn’t seem to be aware of anyone actually using the different types, and said he always uses -A. I’ll think about a way in which most people can just add some aliases there but you can partition them if you want.

maybe accept either alias, alias, alias or -Ralias -Calias or whatever.

If no flag types are entered, then everything is -A.

Makes sense, I think. So you could do something like this :dev, -R:test?

It almost seems like REPLs that are started via :main-opts should be another option entirely.

Why would they need another option?

Because it sounds like there are two distinct tasks a user would want to do: 1. Run a custom REPL launched via :main-opts 2. Start a REPL with a particular set of aliases

Allowing the different alias types would meet both those needs though, right?

I mean, :main-opts comes from an alias.

Right. I was trying to simplify things for users because the tools-deps alias flags can be quite confusing.

Yeah, they are. I think -A by default unless you specify is hopefully a good middle ground.

Perhaps. Though it threw me a bit because I expected the aliases in the "Run with Deps" option to operate in the same way that clicking an alias in the Deps panel does.

Well, they do, except that the ones in the Deps panel are only for dependency resolution, so :main-opts is implicitly ignored since nothing is executed.

Thus my initial confusion.