@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.

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

I have an issue for it

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

Workaround is to use -Sforce

-e, --eval string   Eval exprs in string; print non-nil values

never mind

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

here is the longer stack trace

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

a ha!

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

pretty sure that is the case then

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

right now deps.edn and pom.xml are supported

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

for the time being at least 😉

at least I know which repos I can demo now

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

Not to my knowledge

I suspect it’s bounded by network io usually

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

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

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

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

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

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

that sounds legit…

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

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

although it seems to switch languages rather than offer FFI

hmmm this seems to be the thing

http://www.graalvm.org/sdk/javadoc/org/graalvm/polyglot/Context.html

ok anyway … that’s a different channel

thanks for the help @ghadi

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

https://github.com/raymcdermott/add-lib-demo-app

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