Fork me on GitHub
#tools-deps
<
2018-05-24
>
mhuebert08:05:58

@kenny I just found something that may be related to your issues yesterday. In my mono-repo-of-`:local/root`-projects, if I change one of the deps.edn files inside of a :local/root directory, tools.deps does not recognize the change, and uses its previously cached classpath. I have to make some minor modification to the root deps.edn file (like, add a space somewhere) and then it invalidates the cache. So you may have configured everything correctly and clj was just using an old classpath. Can test for this by running clj -Spath before/after changes to see when it uses the cache vs. when it generates a fresh one.

mhuebert09:05:06

@alexmiller would it be worth creating an issue for this? I am not sure exactly where/how cache invalidation is handled

Alex Miller (Clojure team)12:05:40

Actually looks like maybe I never filed a public issue but I have it in my internal list

4
Alex Miller (Clojure team)12:05:50

Workaround is to use -Sforce

borkdude15:05:08

-e, --eval string   Eval exprs in string; print non-nil values
is it possible to turn off the printing?

genRaiy18:05:08

when using add-lib I sometimes get errors when adding via a git SHA …. Manifest type not detected when finding deps

genRaiy18:05:42

here is the longer stack trace

ghadi18:05:11

raymcdermott you may be add-lib'bing a git repo that has no deps.edn in it

genRaiy18:05:54

@ghadi I did not realize that was a pre-requisite

genRaiy18:05:08

pretty sure that is the case then

ghadi18:05:49

Yeah. tools.deps cannot infer third-party dependencies without some sort of manifest file

4
ghadi18:05:01

right now deps.edn and pom.xml are supported

genRaiy18:05:19

ok, cool so that’s why Maven deps are safer

genRaiy18:05:36

for the time being at least 😉

genRaiy18:05:32

at least I know which repos I can demo now

genRaiy18:05:25

off the wall question … has tools.deps been tried out on graal?

Alex Miller (Clojure team)18:05:04

I suspect it’s bounded by network io usually

genRaiy19:05:13

I was thinking that it probably couldn’t change the classpath

ghadi19:05:12

yeah, it cannot. add-lib will not work over there. Does the REPL work in Graal?

genRaiy19:05:23

I’m guessing that an app can still expose a socket-server

ghadi19:05:11

(I'm assuming you mean the Graal AOT binary part, not just running Graal through JVMCI)

ghadi19:05:44

the repl (whether socket server or otherwise) generates classes, which is incompatible with Graal's AOT native images.

ghadi19:05:07

But all that should work properly through Graal non-AOT (the JVMCI)

genRaiy19:05:44

that sounds legit…

genRaiy19:05:05

so that means - in theory at least - that you can call another language via the REPL

genRaiy19:05:28

they have a polyglot shell so I’m guessing yes at this stage

genRaiy19:05:42

although it seems to switch languages rather than offer FFI

genRaiy19:05:39

hmmm this seems to be the thing

genRaiy19:05:44

ok anyway … that’s a different channel

genRaiy19:05:15

thanks for the help @ghadi

genRaiy19:05:30

btw I made a small demo app with the pre-reqs in place for add-lib

genRaiy19:05:10

I have proven it with my REPL so it might work elsewhere 🙂