Fork me on GitHub
#babashka
<
2020-01-07
>
Nate Sutton01:01:11

man there are so many classes for file manipulation

Nate Sutton01:01:18

setting the owner using nio is just a lot

Nate Sutton01:01:09

you need FileSystem to get a UserPrincipalLookupService in order to look up a UserPrincipal in order to call (Files/setOwner path user-principal)

holyjak06:01:02

It is separation of responsibility. One class for each function and for each concept :rolling_on_the_floor_laughing:

Nate Sutton02:01:52

and then to set the group you need PosixFileAttributeView and GroupPrincipal and maybe all the acl stuff if you're dealing with windows

sogaiu04:01:40

so many yaks to shave...

Nate Sutton04:01:21

it's really something

Nate Sutton06:01:48

I managed to get away with not using the FileAttributeView interfaces

Nate Sutton06:01:20

and I'm punting on ACL until someone actually wants that

borkdude09:01:05

I added some scripts to test babashka libs on CI with new builds of babashka: https://github.com/borkdude/babashka/tree/master/script/lib_tests More libs can be added.

borkdude09:01:41

I was thinking of making a alter-classpath function which you can use to add things to the classpath dynamically in a script. Then you could do something like:

(alter-classpath! (fn [cp] (str cp ":" (:out (shell/sh "clojure" "-Spath" "-Sdeps" ...)))))
in a script to dynamically add libs which you can then require?

jeroenvandijk09:01:23

Would be handy IMO. Maybe also an equivalent to tools.deps add-lib (https://insideclojure.org/2018/05/04/add-lib/)?

borkdude09:01:15

I was thinking about that, but I don't want t couple adding libraries with a specific build tool

borkdude09:01:33

Another scenario: You could for example also just curl some scripts into a directory and then add those dirs to the classpath

jeroenvandijk09:01:18

Makes sense indeed

sogaiu14:01:12

alter-classpath sounds interesting -- will there be an attempt to provide safe-guards somewhere regarding conflicting / problematic dependencies? (cf. alex miller's conj talk)

borkdude15:01:11

haven't thought about it.

borkdude15:01:10

I don't think so. Babashka doesn't resolve any dependencies, it just receives a classpath made by whatever tool

sogaiu16:01:14

understood

borkdude10:01:07

Macroexpand now on bb master:

$ bb "(defmacro foo [x] \`[1 2 ~x]) (macroexpand '(foo 1))"
[1 2 1]

🎉 2
borkdude12:01:24

hooked up some slack integration with circleci in #babashka_circleci_builds

sogaiu14:01:57

macroexpand seems to work here :thumbsup:

sogaiu14:01:19

getting a bit dizzy with the quoting

borkdude21:01:00

Hmm, it seems with the right amount of type hints we don't need to include the Unix specific classes: https://github.com/borkdude/babashka/commit/f1b3180c760c4e3e3c6c6fe5ce983888a642e3a0

borkdude21:01:31

So if I can improve return type inference by reflecting on the static method call, we could remove them...