just VS cargo-xtask

(author of mise)

The biggest advantage just has is that it's been around longer, in mise tasks only came out of experimental like a month ago. mise tasks themselves are stable, but there are still experimental things and some portions that need to be used more—like windows. That said, most of the stuff that needs polish are features just doesn't even have.

I had a look at the top issues for just and pretty much all of them I've handled in mise: https://github.com/casey/just/issues?q=is%3Aissue+is%3Aopen+...

here's my unashamedly biased thoughts on why I like mise tasks compared to just:

- tool integration - this is the obvious benefit. If you run `mise run test` on CI or wherever it'll setup your toolchains and wire them up automatically.

Benefit is you can just type the command, no need to prepend pyqwe or anything.

See also justfile for a non-python specific tool https://github.com/casey/just

This is an interesting approach. These days I have completely switched to just[0] tool for similar use case.

[0]: https://github.com/casey/just

# Palindrome project Project used to explain my view on a django project architecture ## Tools, libs, etc. Some time related files. Versions on Poetry. - [Python](https://www.python.org/) Programming languange - [django-environ](https://django-environ.readthedocs.io) Manage .envs in Django - [Poetry](https://python-poetry.org/) Python packaging and dependency management - poetry.lock - pyproject.toml - [Django](https://www.djangoproject.com/) Web framework written in Python - [Docker](https://www.docker.com/) Manage containers for dev environment - compose.yaml - compose/dev/Dockerfile - compose/dev/start - .env - [Just](https://just.systems/) encapsulate commands for easier use - justfile ## Dev environment setup 1. Install Just, Docker and Poetry(opcional). 2. Copy .env.example to .env, no need for edtion. 3. Certified that docker is up and running 4. `$ just build` ## Run the server for development 1. Certified that docker is up and running 2. `$ just runserver` You can access on http://0.0.0.0:8000/

We heavily use Just at OpenSauced, a command runner utility, much like GNU’s “make”, for easily executing small scripts. This has enabled us to quickly onramp new team members or community members to our Go ecosystem since building and testing is as simple as “just build” or “just test”!

> If I had to submit one tip it would be to set everything up with a Makefile or similar.

If I had to submit a tip on top of yours, it's to use justfiles instead of Makefiles :-)

https://github.com/casey/just

If you’re going to use make, use just instead:

https://github.com/casey/just

💡 Inspired by matklad/cargo-xtask and based on 🏃‍♂️ Write your Rust project scripts in task.rs from the Rust ecosystem.

Using a cargo-xtask task to generate them as a manual step (inlyne currently does this)

As someone else said just is good for that job, or you could implement an xtask helper for these things and setup a suitable development environment with that: https://github.com/matklad/cargo-xtask/

Well tools like cornucopia, prisma-rust-client, protoc-gen-tonic, they don't generate in build.rs, but instead provide either a cli to be called ahead of time, or provide a library that can be called by your own binary (which should generally follow the xtask pattern)

If I understand, this is a tool for when working on the project itself? Akin to a helper script? You could go the cargo install route as already pointed out but there is also the xtask convention.

For simple cli apps for internal use, such as cargo-xtasks, I prefer pico_args due to its fast compile times.