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

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

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

What if you go into a command line REPL?

rlwrap bb

What do you see?

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=> 

client.clj has this test code

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

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

:paths ["script" "resources"]

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

Where does client.clj reside?

in the root of the project. Modified

:paths ["script" "resources" "."]

user=> (require 'client) (in-ns 'client) shellbb
nil
user=> nil
client=> #object[sci.impl.fns$fun$arity_0__7322 0x47185cc1 "[email protected]"]

ok, that is maybe the solution then

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

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

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

Have you restarted your REPL already

Yes, the first thing 🙂

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

I don't see why it wouldn't work

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

shellbb instead of shelltools/shellbb

https://clojuredocs.org/clojure.core/in-ns :)

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

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! : )

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

which will reload the client namespace

It does reload with

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

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

(fs/relativize (fs/path "/home/benj/foo") (fs/path "home/benj/foo/fa"))

@U02CV2P4J6S Hi

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

relativize:

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

you forgot the leading slash in the second path

ah I see

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

What does -r do?

recurse so you can directories

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

			zip -r foo.zip foo

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

it does and every entry is one nested

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

yea

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

yea that works

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

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

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

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

totally

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

exactly

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

yea looks like I would expect it 👍

It probably expects a terminal.

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

(let [opts (merge {:inherit true
                        :dir *cwd*
                        :shutdown p/destroy-tree}
                       (dissoc opts :verbose))

Something’s wrong with the terminal?

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

Sure.

Thanks for having me making a self-contained example.

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

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

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

Perfect, thanks

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

And then do a release shortly after

But he's on vacation this week

So probably somewhere next week

cool, thanks for the pretty quick replies