edit: i'm going to try change the script to a different version of babashka.http-server, and see if that triggers a redownload.

-Sforce, same as Clojure CLI. This problem has been posted a few messages back as well

Can you maybe shrink the original message a bit, it's flooding the channel

https://clojurians.slack.com/archives/CLX41ASCS/p1666129005194539

Posting the original message here in a thread instead:

$ bb_http_server.clj || cat `which bb_http_server.clj`
----- Error --------------------------------------------------------------------
Type:     java.nio.file.NoSuchFileException
Message:  /home/teodorlu/.m2/repository/org/babashka/http-server/0.1.11/http-server-0.1.11.jar
Location: /home/teodorlu/.local/bin/bb_http_server.clj:7:1

----- Context ------------------------------------------------------------------
3: (require '[babashka.deps :as deps])
4: (deps/add-deps
5:  '{:deps {org.babashka/http-server {:mvn/version "0.1.11"}}})
6:
7: (require '[babashka.http-server :as http-server])
   ^--- /home/teodorlu/.m2/repository/org/babashka/http-server/0.1.11/http-server-0.1.11.jar
8:
9: (apply http-server/-main *command-line-args*)

----- Stack trace --------------------------------------------------------------
sun.nio.fs.UnixFileAttributeViews/Basic      - <built-in>
java.util.zip.ZipFile/Source                 - <built-in>
java.util.zip.ZipFile/CleanableResource      - <built-in>
babashka.impl.classpath/path-from-jar        - <built-in>
babashka.impl.classpath.Loader/fn--13316     - <built-in>
clojure.core/some                            - <built-in>
babashka.impl.classpath/source-for-namespace - <built-in>
babashka.main/exec/load-fn--31119            - <built-in>
user                                         - /home/teodorlu/.local/bin/bb_http_server.clj:7:1

#!/usr/bin/env bb

(require '[babashka.deps :as deps])
(deps/add-deps
 '{:deps {org.babashka/http-server {:mvn/version "0.1.11"}}})

(require '[babashka.http-server :as http-server])

(apply http-server/-main *command-line-args*)

Perhaps deps.clj could be more clever here and check that all directories exist on the classpath, to invalidate the cache. This should be a relatively fast operation and easy to do in Clojure (as opposed to bash?). Pinging @U064X3EF3 to see what he thinks of this.

Looks like I'm getting the same error with -Sforce:

$ bb -Sforce .local/bin/bb_http_server.clj
----- Error --------------------------------------------------------------------
Type:     java.nio.file.NoSuchFileException
Message:  /home/teodorlu/.m2/repository/org/babashka/http-server/0.1.11/http-server-0.1.11.jar
Location: /home/teodorlu/.local/bin/bb_http_server.clj:7:1

@U3X7174KS This is because add-deps which probably is used inside that script doesn't "obey" that flag

Just wipe ~/.clojure/.cpcache and ./.cpcache and try again

I'll make an issue for -Sforce + add-deps

Deleted ~/.clojure/.cpcache - and now everything is working. Thanks a lot @U04V15CAJ 🙌

This problem should never happen again https://github.com/borkdude/deps.clj/commit/c2cb64a60beae108913a8935908c3b259047059d

Tank you! 😊

I’ve considered doing that classpath check but it is valid to have empty source dirs so it would need to be a bit nuanced (just looking at jars probably). I would not expect it to be a perf issue in bash (but that’s something to check)

Hmm, empty source dirs. Good point.

Or rather, non-existing source dirs, right

follow up issue: https://github.com/borkdude/deps.clj/issues/69

Hah, I noticed that gitlibs are already covered by the manifests checks, so only checking jar files should be sufficient

That is, removing the gitlibs directory should already work today, without problems

ok, this should do it then: https://github.com/borkdude/deps.clj/blob/33e31d2f9daabadff979ae4d58d2911726c76d4c/src/borkdude/deps.clj#L602-L611

this is kind of a separate question, but is this really a "faithful port" if you add features before the upstream?

That's a good question, that's why I pinged you in this issue as I expected you would have feedback on this.

If you think this is a bad idea, I'll remove it

I think another edge case here is :local/root "foo.jar" which should also not need a new classpath calculation if missing

so, you're right, I'll wait for the upstream then

I will take a look at it, maybe today or tomorrow, not sure yet

ok, reverted and waiting for upstream. https://github.com/borkdude/deps.clj/commit/30bd56472daba5661d4c3f549c2e6572caed57ae at least we got the edge cases more clearly

@U064X3EF3 I see you implemented the .jar checks so I'll go ahead and re-add the code I reverted https://github.com/clojure/brew-install/commit/f791abf1d93563c1ed8f256830bd0bfc085fdd53 Have you thought about the :local/root "foo.jar" case, which does allow missing jar files? It's a bit of a pathological case though, so maybe worth ignoring

Another minor issue: can you maybe change the default branch in that repo to 1.11.1? Then we can see the newest commits right away

As for the non-existing :local/root "foo.jar" case. the tools jar could emit a

.cpcache/01E115B1798E23AB3AB6C356BCC88293.jars

I think it’s right to error if any jar is missing

I’ll get the default branch switched

@U064X3EF3 It doesn't error, it just marks the classpath cache stale. So if there would be a library on the classpath with a :local/root "non-existing.jar" this would always result in a stale classpath check, while no error would be happening similar to non-existing source dirs on the classpath

It should only be stale if it’s missing?

@U064X3EF3 What I'm saying is: • you said it's ok when source dirs are missing • it can also be the case that jar files are missing when people use :local/root "some-jar-file.jar"- what's the difference between src and jar file - that might also be ok? why not? • someone making a mistake in their library could cause end users to always have stale classpath checks with 1177 - it seems wrong that some library's mistake could cause slowness on end users' systems

I'll make an example library to show the problem

The “someone” and “end user” here are the same person in the use case for local jars, which is for pulling local jars into your application for something like a database driver jar

I understand what you’re saying, don’t need an example

I just don’t think it’s an issue

OK. I see the program is erroring with a missing local/root jar, so that's covered then:

$ clj
Error building classpath. Manifest type not detected when finding deps for missing-jar/missing-jar in coordinate #:local{:root "/private/tmp/missing-jar/missing-jar.jar"}

Yeah, that’s what I was expecting

Cool. I think -Sforce will probably be never needed anymore after this change 🤞

Yeah, should be much less relevant

Use of RELEASE is maybe the biggest cause to need it after

Checking another corner case: This isn't supported right? {:paths ["missing-jar.jar"]} But could still trigger the edge case described above

It seems that isn't entirely far-fetched... https://grep.app/search?q=%3Apaths.%2A.jar&regexp=true&filter[path.pattern][0]=deps.edn

If this isn't supported, might want to check if all entries in :paths are directories (if they exist) in tools.deps or still improve the stale check for missing jars?

I’m ok with doing less in the paths check, sometimes there are useful hacks there. The missing jar check error could probably be better

Alternatively you could make a bb/tasks.clj file and require this in your tasks and put your constants etc in there

and add :paths ["bb"]

Those are warnings because those expressions could not successfully be analyzed, perhaps because of :as nil?

But it's intended that it continues despite those warnings

ok, I have the following in the namespace referred in the first warning [com.cohesic.acuity.core2.models.location :as-alias model.location]

(and similar others)

welcome to put together a repro repository, so I can try it locally

could be :as-alias related

ok will do that

I created this one https://github.com/arichiardi/babashka-repros But I actually found the reason of the first issue - there was no namespace backing that alias There are other warnings in there when you run bb build

how to build the uberscript?

See above message, bb build

but there isn't even a bb.edn in this repo

no? wait a sec let me check

@U04V15CAJ apologies, for some reason it was not committed

I suspected as much :) Yes, it definitely has to do with :as-alias, thanks for the repro

https://github.com/babashka/babashka/issues/1403

Yes. You can call (babashka.cli/parse-opts *command-line-args*) of course, but there is also tasks integration: https://book.babashka.org/#_exec