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

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

and this could then also be used for linting

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

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

true

#!/usr/bin/env bash

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

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

having one standalone thing would be handy

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

(just thinking out loud here)

bb install --url https://raw.github.com/foobar/bb.edn --as unwordle ;)

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

https://github.com/clj-kondo/clj-kondo/issues/1550

i kind of like this bb install --as idea

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

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

problem would probably be windows and availabilty of shells

which you can place on the path

Windows can also be supported with a shebang.

or a .bat wrapper

what do you mean availability of shells?

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

(probably too unlikely to consider for now)

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

and on Windows cmd.exe is always there

(have added 1550 to my todo list)

babashka tasks install -g https://....
babashka tasks merge https://....

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

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

then you could pin it to a revision etc

that would make static analysis harder though

that’s true

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

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 ?

namespacing is of course an option 🙂

bb build:lint ...

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

cambrian explosion 🙂

but i think not all of that is mutually exclusive…

true

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

and it’s relatively standalone afaict

the other options probably require some serious hammock time 🙂

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

#!/usr/bin/env bash

bb --config $HOME/build/bb.edn [email protected]

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

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

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

git is ubiquitous

yeah similar situation as bash, at least for now

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

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

oh, that’s a good point

similar to clj-kondo config

the task map could have ^:export ?

for exported tasks

yeah

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

might be a little bit cleaner

{: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

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

gotta run, i’ll bbl 🙂

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

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

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

but the same can be accomplished with a small bash wrapper

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

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

you can already get this sort of with --config

yes, but why not make

bb ../bb.edn tasks

just treat bb.edn as another valid script type

yes and then you could also make it directly executable

using a shebang

exactly

also make it discoverable on classpath

can you give more details?

of course

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)}}}

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"))

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

do you need more info?

I'll try locally, just a minute

all right

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

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

just a minute

use a newer commit: a13b037215e21a2e71aa34b27e1dd52c801a2a7b

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")))))

this prints:

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

that does it

could you explain what was the problem?

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

could be yes

all right, that explains it

thank you once again!