Has anyone ever used `just` instead of `make` as a task runner for a project? If so, how did it work for you? Any feedback?
I have some nontrivial cargo command invocations that need to support parameterization, so I'm considering adding a task runner to the project. Just wondering, should I stick with `make`, or try something new? 
I am still not *quite* ready to put a #justfile in each of my projects (make feels *slightly* better there) but putting one on each of my servers at `~/Justfile` with common server tasks is proving handy 
(I would prefer to find a rpm for my distro for just/uv instead of an install script)
The @tailscale folks have some excellent YT videos on setting up self-hosted servers on Digital Ocean using Terraform, Ansible, and of course, Tailscale. I just got my first Droplet running.
Part 1 - Getting started with cloud-init: https://youtu.be/e-X5FJwrkaA?si=t3iLP-k9B4SmDAMp
Part 2 - Terraform: https://youtu.be/PEoMmZOj6Cg?si=2IwHCw4HuIa71YFZ
Part 3 - Ansible: https://youtu.be/k5Xgt31yK2U?si=28MPbwmiIOB-18nv
Да начнётся новая эра моего заметкописания! Я освоил новую технологию — [typst](https://github.com/typst/typst)! Также используюся:
- <https://github.com/casey/just> — альтернатива make с вменяемым синтаксисом
- <https://github.com/watchexec/watchexec> — следит за изменениями в файлах и запускает команды
Пример кривенького justfile на картинке.
Ok, this seems _pretty ok_. Each project's `justfile` will have a little boilerplate of 2 imports and a `fetch` recipe.
My default justfile can be grabbed with `just fetch` if users want it. The second import is mostly for me and my local filesystem setup.
That should solve for my local dev, make it relatively easy for other devs to get my default `justfile`, _and_ not repeat the same recipes in every project.
I think. We’ll see! 
Sharing so it's easier for me to remember: #justfile recipes can take splat arguments.
+300╭
x5╭⁂+3╭(Ⓐ+a 
test *args:
pytest tests {{ args }}
Means I can do
just test -xk Links
and that'll expand to
pytest tests -xk Links
I think you could quite easily achieve this workflow by defining a command wrapper (shell script, or even shell alias) that converts `dock project1 up` to `docker compose -f /var/docker/compose/project1.yaml up`.
That would be pretty handy IMHO, `docker compose up -d && docker compose logs -f --since=1m` is a hell of a lot to type (I alias it using #Justfile to `just up`)
Unreasonably pleased by a tiny tweak to #plaintextaccounting scripts. I keep most of them in a #Justfile. I have these useful help/h recipes:
# list recipes, optionally filtered by REGEX.
@help *REGEX:
if [[ '{{ REGEX }}' == '' ]]; then just -lu; else just -lu --color=always | rg --pcre2 -i '{{ REGEX }}'; true; fi
alias h := help
and shell alias j=just; so to list foo-related scripts I’m often typing
j h foo
It's short, but… I added alias h='just help’, now it’s much better:
h foo
FOSS service with a smile: I submitted an issue https://github.com/casey/just/issues/1858 that was giving me #justfile heartburn. A couple hours later and the maintainer has committed an implementation. Lesson: Ask nicely and do some homework and you'll (sometimes) be rewarded.
And the next part: importing transactions you may have forgotten but your forecast rules have not. Nicely avoids importing transactions twice.
YEAR := `date +%Y`
FORECASTJ := YEAR / YEAR + '-forecast.journal'
# import any recent transactions generated by forecast rules; --dry to preview
@import-forecast *ARGS:
hledger import -s -I --auto --forecast=-15days..tomorrow {{ FORECASTJ }} "$@"
(import explained: https://hledger.org/dev/hledger.html#import)
(In future, if osh/ysh get some make/just-inspired features or libraries (seems quite possible), the pendulum may swing back to using shell only.
I'm using `just` eg to manage developer/maintainer task scripts for #hledger, and to manage personal finance/time/task scripts.
Here's one for showing a near-term transactions forecast:
# show forecast transactions predicted recently and soon
@forecast *ARGS:
hledger print -I --auto --forecast=-15days..+15days tag:generated "$@"
(Forecasting explained: https://hledger.org/dev/hledger.html#forecasting)
You can achieve some of these things with make, if you work hard enough, and ensure you have the right version, but it's more complicated, more fragile, less portable, and harder for others to understand.
Why I’m using `just` for script management after many years with make/shell:
- you can easily list recipes with their docs
- recipes have robust argument handling
- easier and smoother integration with scripting languages
- much fewer idiosyncracies
- more portable (one version, more likely to work on Windows)
- makes things more robust
- frees up vital head space.
You have to install it; and you lose the ability to depend on other outputs, for now.
In which I share comparable make/bash scripts and a justfile, including some nifty scripts; and touch on why I've adopted just after many years with make and bash:
https://news.ycombinator.com/item?id=38811688
As a bonus for anyone using my #AdventOfCode template, I've added support for the `advent` program in my Universal Test Runner!
This means you can run your solution by just pressing `t`!
For anyone not using my template, you can create a #makefile or #justfile with your own command and the test runner will pick it up too!
@mongrelion awesome on the usage! I highly recommend reading the manual. There's a lot of capacity it provides.
That said, #justfile do have conditional expressions you can build. However, justfile goal is to be a command runner and only that. Instead of discouraging to write a script, you can use the interpreter of whatever on it directly. Meaning you can go straight to python instead if you need a full language. Not just bash.
