Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-08-31

Channels

#babashka
<
2022-08-31
>
mkvlr10:08:19

one thing I'd often want to have is a flag in bb tasks to not execute dependent tasks. I'd find that useful when interactively working on a script. Do other folks feel that need as well?

borkdude10:08:57

@mkvlr I think you could just put the task code in a .clj file (which is recommended anyway when your task code grows beyond a couple of lines)

borkdude10:08:28

There is now bb -x tasks/my-task --foo 1 --bar 2 as well

borkdude10:08:44

if you have a tasks.clj or file and add ["."] to :paths

mkvlr10:08:22

hmm, think I'd still find it useful to not execute deps, especially when using bb to automate just simple shell invocations

borkdude10:08:29

(or put it in a bb directory and add that to :paths )

borkdude10:08:51

you could just comment out :depends temporarily maybe

mkvlr10:08:29

that works but probably not convenient enough to actually make me do it as opposed to waiting the extra time…

borkdude10:08:03

then maybe it's not that important? ;)

mkvlr10:08:03

if I'm alone in wanting this probably not

borkdude10:08:34

how do you invoke the task interactively - with run?

borkdude10:08:35

I think there is a maybe a better solution here: to make :release-js not do anything if there's nothing new to build. https://blog.michielborkent.nl/speeding-up-builds-fs-modified-since.html

mkvlr10:08:40

this is a task that's run on CI where release:js needs to run before

mkvlr10:08:07

but when developing it locally and I ran it once I don't want to re-run it all the time

mkvlr10:08:18

figuring out if there's nothing new to build isn't so simple though

mkvlr10:08:27

is there also a content-addressed equivalent of fs/modified-since?

mkvlr10:08:00

if there was an easy way to get a hash for a tree skipping extra work might become a lot easier & reliable

borkdude10:08:17

we've been doing something like this in nextjournal/nextjournal and ductile

borkdude10:08:13

tbh I think the least amount of effort is to just comment out :depends and then turn it back on

borkdude10:08:57

but I'll keep it in mind if it comes up more often

lread11:08:13

I suppose your long running task(s) that you want to typically skip during dev could simply check if it should run? Maybe check an env var? Or an option on the command line? Or is that still too clumsy?

mkvlr12:08:14

I'm interested in having the deps declared via :depends and skipping those. Over lunch I came to the conclusions that declaring them in an external file and manually invoking them via bb -x is fine I guess. I guess adding a flag for this isn't easy either as it would conflict with the args of the task?

Andrea11:08:06

maybe following on the same topic: how would I quickly test some task from command line before it lands as value to a :task key in bb.edn but retaining the same context, say :paths and :deps of the bb.edn ?

borkdude11:08:07

Not sure I get your question. Do you have an example?

borkdude11:08:47

Are you asking: how do I test a dependency? Do you mean, print the result of a dependent task? You can run it with: 

bb run --prn dependent-task

Andrea12:08:14

say I have: 

{:paths ["ops/src"]
 :tasks 
 {my-task {:depends [do-this-first]
           :task (do (do-this) (do-that))}}}
but I want to just test do-this which maybe uses some functions defined at ops/src. Maybe I should just ensure such fns do work in the REPL...

borkdude14:08:49

yeah, just define those in a .bb or .clj file.

borkdude14:08:58

you can invoke them with -x too