Fork me on GitHub
#cursive
<
2015-10-27
>
cfleming00:10:12

@micah: So the problem is that the plugin is messing with :eval-in - I’ll see if I can find a fix for that.

cfleming00:10:56

@micah: I do get all the test output, which looks correct as far as I can tell.

stijn09:10:03

@cfleming: with 0.1.67 a dependency like yada:1.0.0-20150903.093751-9 is not being picked up

cfleming09:10:50

@stijn: Possibly - that looks like a concrete version of a snapshot dep, right?

cfleming09:10:59

Do you have an explicit dependency on that version?

stijn09:10:26

anything in the tree under that dependency neither

stijn09:10:47

the repl does run however, but the editor doesn't recognize the symbols

stijn09:10:17

@cfleming: yes, an explicit dependency

cfleming09:10:21

If you change it to yada:1.0.0-SNAPSHOT, I believe it should work. Is there a reason you’re depending on an explicit version of a snapshot?

stijn09:10:37

no reason, i'll try that

stijn09:10:42

that fixes it yes

stijn09:10:57

the reason was that I was switching between checkouts and a released snapshot earlier

cfleming09:10:21

@stijn: Interesting use case though, I can imagine that you might want to pin to a specific snapshot version.

cfleming09:10:16

Could you file an issue for that, and I’ll fix it when I get a moment?

stijn09:10:22

okay, will do

cfleming09:10:21

I’m not entirely sure how I’ll fix that one, since it’s tricky to support both -SNAPSHOT versions and the explicit ones.

micah14:10:21

@cfleming: With the -a flag (auto run), speclj will stay alive re-run any specs affected by file changes. What’s the fix? Is it in the script you pasted?

micah14:10:52

@cfleming: Also, as I try to debug this, I get a Cursive error every time I “lein install” speclj: java.io.EOFException: Unexpected end of ZLIB input stream, compiling:(leiningen/spec.clj:49:7) I have to restart InstalliJ to get passed this.

danielcompton19:10:55

Ah, I was running into this issue with snapshot dependencies the other day too, but I thought I was doing something wrong

danielcompton19:10:17

It’s fairly common for us to pin a snapshot dep, especially in the CLJS world where things move so quickly

cfleming21:10:53

@danielcompton: Yeah, that makes sense. I’ll see if I can do something sensible with that case.

danielcompton21:10:14

what makes it a special case?

danielcompton21:10:22

Isn’t it just a normal dependency?

cfleming21:10:44

@micah: Ah, that makes sense. The fix is a code fix, I’ll send you a dev build to play with shortly. Are you on IntelliJ 14.1?

cfleming21:10:21

@danielcompton: The problem is when you have a snapshot dep brought from a repository. The deps come back with two versions, the “resolved version”, which is the -20150903.093751-9 one, or the “base version” which is the -SNAPSHOT one.

cfleming21:10:16

The project.clj will only have one of those two versions specified, and it looks like I really have to try to match both to the dependencies which come back.

cfleming21:10:13

It gets tricky when you have snapshot deps which depend on other snapshots, especially if some are pinned and some are not.

danielcompton21:10:30

yep that was the situation I was in

danielcompton21:10:41

I had a lein plugin snapshot, depending on a clojure lib snapshot

danielcompton21:10:54

I was trying to pin both of them. I gave up in the end

cfleming21:10:55

So that case was the case I fixed on the weekend, because when you depend on -SNAPSHOT, aether (lower-case, the Clojure one) returns the resolved version, and Cursive didn’t match them correctly.

cfleming21:10:14

But I’ll have to fancy up the matching to handle both cases.