Fork me on GitHub
#babashka
<
2022-06-01
>
dabrazhe09:06:11

Here is the workflow issue I am facing. The client namespace requires another namespace, a kind of library of functions, let's call it shelltools.

(ns client
  (:require [shelltools :refer :all]))
(ns shelltools) has functions defined, eg (shellbb)
I can evaluate the (ns client .. ) form and VS Code even shows the (shellbb) function in Intellisense. However, invoking shellbb fails, because (ns shelltools) and the function have not been yet evaluated in the Repl. I have to go manually into each of the files like shelltools and evaluate them every time the Repl disconnects. There should be a way to streamline this.

borkdude09:06:52

> I can evaluate the (ns client .. ) form After doing so, shellbb should work I think?

borkdude09:06:01

I'm not sure I understand the issue. How is this different from normal Clojure?

dabrazhe09:06:27

That's the thing, it does not. None of the forms in (ns shelltools) are available in the (ns client) unless I switch to (ns shelltools) and explicitly evaluate them

borkdude09:06:41

What if you go into a command line REPL?

rlwrap bb
and then (require 'client) (in-ns 'client) shellbb

borkdude09:06:43

What do you see?

dabrazhe09:06:34

user=> (require 'client) (in-ns 'client) shellbb
java.lang.Exception: Could not find namespace: client.
user=> nil
client=> Could not resolve symbol: shellbb [at <repl>:1:35]
client=> 
It can't find client either..

dabrazhe09:06:34

client.clj has this test code

(ns client
  (:require [shelltools :refer :all]))

dabrazhe09:06:27

It's in the root directory. bb.end has path defined

:paths ["script" "resources"]

borkdude09:06:55

If you can't find client in the console REPL, something is not right

borkdude09:06:18

Where does client.clj reside?

dabrazhe09:06:31

in the root of the project. Modified

:paths ["script" "resources" "."]
New result
user=> (require 'client) (in-ns 'client) shellbb
nil
user=> nil
client=> #object[sci.impl.fns$fun$arity_0__7322 0x47185cc1 "sci.impl.fns$fun$arity_0__7322@47185cc1"]

borkdude09:06:57

ok, that is maybe the solution then

dabrazhe09:06:47

Thus it appears to work as expected in the console Repl )

dabrazhe09:06:43

But won't work in VS Code repl (calva)

clj꞉user꞉> 
nil
clj꞉client꞉> 
; : Could not resolve symbol: shelbb client /

borkdude09:06:07

Have you restarted your REPL already

dabrazhe09:06:22

Yes, the first thing 🙂

borkdude09:06:42

Can you publish this repo or make another repro of this that I can check out locally?

borkdude09:06:49

I don't see why it wouldn't work

dabrazhe09:06:24

You are right, it does! My fault. I was calling it wrong (

shellbb instead of shelltools/shellbb
What does (in-ns 'client) do?

dabrazhe09:06:08

Yep, I kind of expected a link to the docs :))

dabrazhe10:06:23

The issue was the link to the project root directory in the :path. I have to re-evaluate the library ns file when I make changes to it, but I can live with it. Beats restarting the repl) Thanks a lot for the great and fast help, as usual! : )

🎉 1
borkdude10:06:39

You can evaluate (require '[client] :reload) perhaps

borkdude10:06:46

which will reload the client namespace

dabrazhe10:06:49

It does reload with

(ns client (:require [shelltools :refer :all ] :reload))
Thanks a lot!

👍 1
Benjamin11:06:06

Jo I would like to zip and the resulting zip should be relative to some other dir. Like this ./a/b/c -> should end up as c

Benjamin11:06:59

because I want to zip something that is deep in a file tree. I can also make workarounds with copying into a temp dir or sth

Benjamin12:06:08

(fs/relativize (fs/path "/home/benj/foo") (fs/path "home/benj/foo/fa"))
related, how do I use this function?

borkdude12:06:46

So how are you calling zip? Can you give the full code?

borkdude13:06:40

relativize:

user=> (fs/relativize (fs/path "/home/benj/foo") (fs/path "/home/benj/foo/fa"))
#object[sun.nio.fs.UnixPath 0x48ca19b3 "fa"]

borkdude13:06:51

you forgot the leading slash in the second path

Benjamin13:06:13

well I'm cheating now and call (shell/sh "zip" "-r" zip-file dist-name)

borkdude13:06:36

What does -r do?

Benjamin13:06:49

recurse so you can directories

Benjamin13:06:16

-r
	--recurse-paths
		Travel the directory structure recursively; for example:

			zip -r foo.zip foo

borkdude13:06:50

It isn't clear to me if the zip contains the foo directory or not

Benjamin13:06:14

it does and every entry is one nested

borkdude13:06:37

so if you unpack foo.zip then foo will be created?

borkdude13:06:48

This is the same with (fs/zip "foo.zip" ["foo"])

Benjamin13:06:58

yea that works

borkdude13:06:40

@U02CV2P4J6S So it's not necessary to cheat anymore, do I understand correctly, or is something missing?

Benjamin13:06:25

What was hard for me was figuring out something where the entries don't end up nested so deep. I ended up copying the tree (foo) then zip

borkdude13:06:04

Ah so you would like (fs/zip "foo.zip" [{:file "foo/bar/baz" :root "foo/bar"}]) or so right?

borkdude13:06:24

(this does not work right now, just an idea)

Benjamin13:06:56

so the zip doesn't end up with foo/bar everywhere

borkdude13:06:37

Does the syntax look ok to you? https://github.com/babashka/fs/issues/67 I think it's worth trying in a PR

Benjamin13:06:26

yea looks like I would expect it 👍

pinkfrog13:06:11

I am seeing this error when I launch the tool pgcli https://www.pgcli.com/ with bb.

(defn- run-pgcli*
    []
    (let [cmd "pgcli 'host=localhost port=5432 dbname=example user=example password=example'"]
      (sh cmd)))
WARNING: your terminal doesn’t support cursor position requests (CPR).

borkdude13:06:31

It probably expects a terminal.

borkdude13:06:58

If you want to have interactivity, you probably want to use (process "pgcli '...'" {:inherit true})

pinkfrog13:06:28

(let [opts (merge {:inherit true
                        :dir *cwd*
                        :shutdown p/destroy-tree}
                       (dissoc opts :verbose))
I do have the :inherit option set.

pinkfrog13:06:47

Something’s wrong with the terminal?

borkdude13:06:06

That wasn't obvious from your previous snippet. Could you maybe write a standalone repro that is fully self-contained?

pinkfrog13:06:12

Thanks for having me making a self-contained example.

pinkfrog13:06:42

It turns out I have another process running, which also have {:inherit true} and this somehow interferes with the pgcli process.

👍 1
pinkfrog13:06:16

another sibling process. It is spawned along with the pgcli process from the same parent process.

perpen13:06:27

hola - is there something like a *bb-version* available from code, or do i need to run bb --version ? and @borkdude when are you planning to release next? i'm using the new exec like you mentioned to me on github (thanks again), but i'm not gonna bother implementing workarounds if you release quickly (no pressure, really 🙂 )

borkdude13:06:54

@U03J48P76RW (System/getProperty "babashka.version")

perpen13:06:41

Perfect, thanks

borkdude13:06:02

I want to wait on some feedback from @U055XFK8V if the current babashka master contains enough for the schema.core PR to make it compatible with bb

borkdude13:06:12

And then do a release shortly after

borkdude13:06:17

But he's on vacation this week

borkdude13:06:23

So probably somewhere next week

perpen13:06:34

cool, thanks for the pretty quick replies