Fork me on GitHub
#babashka
<
2022-03-25
>
mike_ananev08:03:25

Hello. I’ve got a problem with at-at How to fix Method cancel on class java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask not allowed! ?

1
👍 1
borkdude08:03:17

Issue welcome. We need to add a reflection config for that

lsyoyom17:03:49

Hello! I've a problem with tasks and dependencies:

{:tasks
 {-dep-1 (println "dep-1")
  -dep-2 (println "dep-2")
  -dep-3 {:depends [-dep-1]
          :task (println "dep-3")}
  -dep-4 {:depends [-dep-2]
          :task (println "dep-4")}
  -dep-5 {:depends [-dep-3]}
  main {:depends [-dep-3 -dep-4]
        :task (run '-dep-5)}}}
And the output when bb main is run:
$ bb main
dep-1
dep-3
dep-2
dep-4
dep-1
dep-3
How can I avoid re-run of dep-1 and dep-3?

dpsutton18:03:19

that kinda makes sense to me. you said it explicitly depends on dep 3, and then dep 5 itself knows it depends on dep 3.

lsyoyom18:03:16

Do you mean I shall remove -dep-3 from main's :depends?

dpsutton18:03:15

that would be my guess

Björn Ebbinghaus18:03:00

Is it possible to dynamically remove deps from the classpath? Or change their version?

Björn Ebbinghaus18:03:24

I thought about using babashka to test for breaking changes between versions of a lib

load deps version 1
create db in memory
write to db

unload version 1
load version 2

read from db

borkdude18:03:01

Yes. You can do this using babashka.deps/add-deps which takes a deps.edn-shaped map

borkdude18:03:28

You can only add, but not remove from the classpath

borkdude18:03:44

But of course you could start a new bb process with a fixed classpath from within bb itself

Björn Ebbinghaus19:03:45

Ok... I'll try that. But:

(deps/clojure (list* "-M" "-e" "(+ 1 2)"))
; or
(process/process ["clj" "-M" "-e" "(+ 1 2)"])
both return: ; : Multiple methods in multimethod 'simple-dispatch' match dispatch value: class babashka.process.Process -> interface clojure.lang.IDeref and interface clojure.lang.IPersistentMap, and neither is preferred user Am I doing something wrong?

borkdude19:03:25

This is because of printing the process result. There's an open issue about this

lsyoyom18:03:22

@dpsutton I think I used a wrong way to express my problem, let me try it again 😛 I have a few tasks, like my final tasks is a

(do
  (run 'task1)
  (run 'task2)
  (run 'task3))
And all of them require a few common stage setting tasks. so they interdepends on a few common depends. I want to be able to only run those common deps for only once. but when I have the above structure, task1 would run common depends once and so does the run of task2 and task3. Is there any way to avoid that?

lsyoyom18:03:39

Is this something achievable in bb? Or some way to structure the depends and tasks I shall use to solve it?

borkdude18:03:37

@lin.subscriber I would define a task that depends on task 1, task 2 and task 3 and then run that task. This will achieve that goal:

main {:depends [task1 task2 task3]}

borkdude18:03:07

Using babashka.tasks/run will run the task including all dependencies.

borkdude18:03:19

If you want a dependency to run only once over multiple run invocations then you should code something e.g. using a delay

lsyoyom19:03:24

I tried a few different ways, the issue I run into seems to be I'm not sure how to share a variable that's defined in one particular task run to be carried to the next task run, it seems the [:tasks :init] would re-run and the previously defined variables / keys are cleared.

borkdude19:03:39

@lin.subscriber Ah clear, yes. If you want to do this, you should make a separate namespace and put your code there. That namespace will be loaded only once

lsyoyom19:03:24

I see. Like an atom in my own namespaces via :path ["script"] ?

borkdude19:03:44

yes via :paths ["script"]

lsyoyom19:03:58

(def state (atom {}))

lsyoyom19:03:17

I see, thanks, I will give that a try too.

lsyoyom18:03:20

Thanks, @borkdude, let me give that a try.

lsyoyom19:03:26

Could you elaborate a bit more on the delay idea?

1