Fork me on GitHub
#babashka
<
2022-01-20
>
borkdude09:01:23

Thanks to @maximilian in the next release of clj-kondo:

❤️ 4
borkdude10:01:20

Any feedback on this?

mknoszlig10:01:16

it would make picking it up for linting a bit harder i guess

borkdude10:01:16

yeah, we could support ^:babashka/tasks as metadata as a pre-condition to make this file executable or so

borkdude10:01:22

and this could then also be used for linting

mknoszlig10:01:02

but having the option of putting it on path and having it available globally would be a big plus indeed

borkdude10:01:15

you can already do the above using a small bash wrapper btw

borkdude10:01:56

#!/usr/bin/env bash

bb --config <location-of-bb-.edn>

borkdude10:01:27

but if you want to distribute that, that would be two things to download: the bash wrapper + the bb.edn

borkdude10:01:41

having one standalone thing would be handy

mknoszlig10:01:33

maybe there could be bb bin-script --config <location> to create such a wrapper?

mknoszlig10:01:08

(just thinking out loud here)

borkdude10:01:18

this reminds me , we could make a linter for task names that shadow built-in tasks

mknoszlig10:01:37

i kind of like this bb install --as idea

borkdude10:01:25

and also a dir? --dir /usr/local/bin

borkdude10:01:46

we could have a default dir ~/.babashka/tools or so

mknoszlig10:01:51

problem would probably be windows and availabilty of shells

borkdude10:01:52

which you can place on the path

borkdude10:01:21

Windows can also be supported with a shebang.

borkdude10:01:37

or a .bat wrapper

borkdude10:01:54

what do you mean availability of shells?

mknoszlig10:01:39

well, if for some reason /bin/env bash isn’t available on the system

mknoszlig10:01:10

(probably too unlikely to consider for now)

borkdude10:01:29

yeah, I think we can work that out, e.g. choosing bash, zsh or whatever is available

borkdude10:01:39

and on Windows cmd.exe is always there

mknoszlig10:01:13

(have added 1550 to my todo list)

borkdude10:01:26

babashka tasks install -g https://....
babashka tasks merge https://....
merge would merge remote tasks into the current project

borkdude10:01:13

I've already considered merge in an issue by weavejester, it comes with some caveats like naming conflicts

mknoszlig10:01:54

hmm… this almost looks like it could be a task-deps in bb.edn again?

mknoszlig10:01:21

then you could pin it to a revision etc

borkdude10:01:49

that would make static analysis harder though

mknoszlig10:01:28

that’s true

borkdude10:01:53

{:tasks {:subtasks {foo {:extra-deps ... a {....}}}}
bb foo:a

mknoszlig10:01:55

for merge and conflicts: how about the default behaviour is to fail on conflict and have additional cmd-line opts like --overwrite task-a,task-b --keep-existing task-c ?

mknoszlig10:01:22

namespacing is of course an option 🙂

borkdude10:01:48

bb build:lint ...

borkdude10:01:00

hmm, lots of options to think about, too many ;)

mknoszlig10:01:09

cambrian explosion 🙂

mknoszlig10:01:31

but i think not all of that is mutually exclusive…

mknoszlig10:01:32

i like the wrapper generator because it would be a consistent way to create standard cli tooling

mknoszlig10:01:40

and it’s relatively standalone afaict

mknoszlig10:01:09

the other options probably require some serious hammock time 🙂

borkdude10:01:05

I have a build script in my bin folder like this:

#!/usr/bin/env bash

bb --config $HOME/build/bb.edn $@

borkdude10:01:42

where $HOME/build/bb.edn is a git clone of https://github.com/weavejester/build

borkdude10:01:02

so we could just support that: a wrapper script + a git clone

borkdude10:01:18

and the project will be git cloned in some dedicated dir or so

borkdude10:01:46

git is ubiquitous

mknoszlig10:01:46

yeah similar situation as bash, at least for now

borkdude10:01:12

this also requires a little hammock time since the project bb.edn might not always be the exported bb.edn

borkdude10:01:23

since the project bb.edn might contain build tasks specific to the project

mknoszlig10:01:38

oh, that’s a good point

borkdude10:01:49

similar to clj-kondo config

mknoszlig10:01:59

the task map could have ^:export ?

mknoszlig10:01:34

for exported tasks

borkdude10:01:52

or {:tasks {a {:export true}}

borkdude10:01:57

might be a little bit cleaner

mknoszlig10:01:20

{:tasks {a ^:export (do something)}} would be possible i guess, but i think you’re right, it’s more consistent requiring the map version here

mknoszlig10:01:00

(since exported tasks are hopefully even more likely to have doc strings)

mknoszlig10:01:05

gotta run, i’ll bbl 🙂

Dig18:01:05

maybe unrelated but i would settle for https://github.com/clojure/tools.deps.alpha/blob/f96c0baae1a07ab1c0f914d7baea8c8de2e427eb/src/main/clojure/clojure/tools/deps/alpha.clj#L106 to find bb.edn so when i run bb task it will look in some global bb.edn

borkdude18:01:07

This is not about a user deps.edn/bb.edn

borkdude18:01:38

It was more about having bb.edns as a standalone thing that you could distribute

borkdude18:01:45

but the same can be accomplished with a small bash wrapper

Dig18:01:06

i see, if you make logic to find bb.edn more advance, it would be just curl bb.edn and then bb tasks

borkdude18:01:41

yeah or curl bb.edn -> something and then something tasks

borkdude18:01:06

you can already get this sort of with --config

Dig18:01:57

yes, but why not make

bb ../bb.edn tasks
work w/o config

Dig18:01:31

just treat bb.edn as another valid script type

borkdude18:01:48

yes and then you could also make it directly executable

borkdude18:01:55

using a shebang

Dig18:01:38

also make it discoverable on classpath

João Pedro de Amorim Paula19:01:05

hello hello, everyone! i'd like to know if there is any way to declare a variable before babashka tries to load dependencies. i'm trying to get babashka to run some [kaocha's](https://github.com/lambdaisland/kaocha) tests without the overhead of using lein in the command line (i'm on a project that already has lein setup for tests, it would not be ideal to replicate the lein test setup to run a couple of tests using clj in a very specific workflow), but it complains that the symbol *clojure-version* isn't defined. i tried doing it as

BABASHKA_PRELOADS='(def *clojure-version* "1.10.3.1058")' bb -m pre-push
but that still fails. is the only way asking/contributing to kaocha to make it run with babashka?

João Pedro de Amorim Paula19:01:19

also great work on it, folks! babashka is a very amazing tool!!!

borkdude19:01:35

@jpedrodeamorim you can do this indeed via preloads, but are you trying to run tests written for babashka code or for jvm code?

borkdude19:01:24

then you also have to load kaocha on the JVM, there is no way around that

João Pedro de Amorim Paula19:01:39

i'm trying to define a pre-push script to be run on GitHub hooks to test only the files changed

borkdude19:01:34

you have to do a more advanced analysis as namespaces can depend on each other. there is a tools namespace port available for babashka: https://github.com/babashka/tools.namespace

João Pedro de Amorim Paula19:01:25

i was already eying tools.namespace

borkdude19:01:37

I've written babashka code for a similar problem at nextjournal where we cache CLJS builds if the code hasn't changed

João Pedro de Amorim Paula19:01:49

would the code for that be available anywhere? sounds like it intersects a lot with what i'm trying to accomplish indeed

borkdude19:01:12

the code isn't public but I bet @mkvlr doesn't mind if I share this function:

(defn cljs-files
  "Returns CLJS files + CLJ files that contain related macros from dirs."
  [dirs]
  (let [cp-dirs dirs
        direct-inputs (mapcat #(glob-sources % "**.{cljs,cljc}") cp-dirs)
        cljs-namespaces (map ns-file/read-file-ns-decl direct-inputs)
        cljs-deps (set (mapcat ns-parse/deps-from-ns-decl cljs-namespaces))
        clojure-files (find-clojure-files cp-dirs cljs-deps)
        ;; The assumption is that macro namespaces do not have dependencies on
        ;; other .clj namespaces. So far that assumption seems to hold.
        macro-files (keep #(when (str/includes? (slurp %) "defmacro")
                             %) clojure-files)]
    (println "Macro namespaces: "macro-files)
    (concat direct-inputs macro-files)))

👍 2
João Pedro de Amorim Paula19:01:13

i could also look into using plain clojure.test for it as well, instead of kaocha, given that we only want to run unit tests on pushes. integration and more complicated test suites are only run on merges

borkdude19:01:19

so you have to fiddle a bit with ns-parse/deps-from-ns-decl and calculate some transitive tree of namespaces

👀 1
borkdude19:01:11

so if you make a change in namespace X and X is used in Y, you'll also have to run the tests for Y

borkdude19:01:39

it's a tricky problem since this is assuming that testing is based on namespace organization

João Pedro de Amorim Paula19:01:20

yup, i'm trying to build some ad-hoc dependency tree for that purpose

João Pedro de Amorim Paula19:01:34

thank you for sharing the code

João Pedro de Amorim Paula19:01:41

and for the quick response as well!

👍 1
João Pedro de Amorim Paula20:01:34

hey, sorry to bother again

João Pedro de Amorim Paula20:01:05

but i'm trying to use babashka's fork of tools.namespace but i'm getting a Could not resolve symbol: *clojure-version* 😕

borkdude20:01:02

can you give more details?

João Pedro de Amorim Paula20:01:33

here is bb.edn:

{:paths ["script"]
 :tasks
 {pre-push {:extra-paths ["test"]
            :extra-deps {org.clojure/tools.namespace
                         {:git/url ""
                          :git/sha "56088a1e6fa8a87683c8c13a93d37af39ef8ccc9"}}
            :requires ([pre-push])
            :task (pre-push/-main)}}}

João Pedro de Amorim Paula20:01:40

and on the pre-push file i have

(ns pre-push
  (:require
    [clojure.tools.namespace.parse :as ns-parse]))

(defn -main []
  (ns-parse/read-ns-decl "foo.clj"))

João Pedro de Amorim Paula20:01:46

running bb run pre-push gives the following error:

----- Error --------------------------------------------------------------------
Type:     clojure.lang.ExceptionInfo
Message:  Could not resolve symbol: *clojure-version*
Location: clojure/tools/reader/impl/utils.clj:17:35
Phase:    analysis

borkdude20:01:37

I'll try locally, just a minute

João Pedro de Amorim Paula20:01:22

i have also tried using preloads, defining *clojure-version* as a dynamic var and normally, but still the same error comes up

borkdude20:01:23

no, it shouldn't be loading tools reader at all

borkdude20:01:25

just a minute

borkdude20:01:57

use a newer commit: a13b037215e21a2e71aa34b27e1dd52c801a2a7b

borkdude20:01:03

And then this works:

(ns pre-push
  (:require
   [clojure.tools.namespace.parse :as ns-parse]
   [ :as io]))

(defn -main []
  (prn (ns-parse/read-ns-decl (java.io.PushbackReader. (io/reader "script/pre_push.clj")))))

borkdude20:01:19

this prints:

(ns pre-push (:require [clojure.tools.namespace.parse :as ns-parse] [ :as io]))

João Pedro de Amorim Paula20:01:02

could you explain what was the problem?

João Pedro de Amorim Paula20:01:49

i was using the SHA for one of the tags. was that a SHA for the original, unforked lib?

borkdude20:01:00

could be yes

João Pedro de Amorim Paula20:01:16

all right, that explains it

João Pedro de Amorim Paula20:01:20

thank you once again!

👍 1