20 ms·

Just: A Command Runner

482 points by tnorthcutt 4y ago

brabel 4y ago
It seems to me much nicer choice is https://taskfile.dev/ https://taskfile.dev/ Just doesn't seem to even support caching task results (by declaring inputs/outputs)?
xwowsersx 4y ago
The manual appears to be busted. The installation docs at https://just.systems/man/en/chapter_2.html#installation https://just.systems/man/en/chapter_2.html#installation just (ha) shows an empty page.
- Jtsummers 4y ago
  Try going to the subsections inside of Installation. https://just.systems/man/en/chapter_4.html https://just.systems/man/en/chapter_4.html
  - xwowsersx 4y ago
    Ah thank you
- JacobLinney 4y ago
  I believe this is just due to how they're parsing the README.md on https://github.com/casey/just https://github.com/casey/just. (Though this should probably still be updated) The installation section has no direct body, but there are subheaders with the actual instructions. Ex. https://just.systems/man/en/chapter_3.html https://just.systems/man/en/chapter_3.html
velcrovan 4y ago
One of the listed benefits of just is "Recipes can be listed from the command line." There is a nice trick that gives makefiles this ability: http://marmelab.com/blog/2016/02/29/auto-documented-makefile.html http://marmelab.com/blog/2016/02/29/auto-documented-makefile... Adding .PHONY targets and so forth is a bit inelegant, but I can share a makefile with confidence that any Linux/Mac OS/BSD user can use it without needing additional software, and I will never have to worry about make becoming unavailable or no longer maintained. Just my personal opinion.
- rcarmo 4y ago
  Actually, I did a hack that does that too (this one is nicer, though). I can’t find mine offhand (too many makefiles), but it is also a Makefile target that runs grep -B1 on the Makefile itself and spits out each target’s name and the comment I usually add to it… And my Makefile template uses .env files too… I think I cover most of the list in my day-to-day use.
  - oso2k 4y ago
    That works well if you have targets with simple comments that are directly above the target and don't extend beyond a single line. It may be important to provide several lines of help. This gist has other solutions as well: https://gist.github.com/prwhite/8168133 https://gist.github.com/prwhite/8168133
- codetrotter 4y ago
  > I can share a makefile with confidence that any Linux/Mac OS/BSD user can use it without needing additional software Makefile portability can be tricky. Especially if you try to do something fancy with the makefiles. GNU Make has features and syntax that the other Makes don’t. Likewise there are features and syntax that some Make programs have that GNU Make doesn’t.
- deleted 4y ago
  [deleted]
- dijit 4y ago
  > but I can share a makefile with confidence that any Linux/Mac OS/BSD can use it without needing any additional software I'm sure you're kidding, but in the case that you're not: Make portability is gross. We have ./configure steps precisely because Make is difficult w.r.t. portability, but even if that wasn't the case and you were just using make as a command executor: you still have enormous warts. Oh, and yeah, you'd need whatever additional software too. Be it: headers, linters, formatters, libraries or test suites that you've bundled. Valgrind is a popular make target, but "Make" does not bring in valgrind (for example). Honestly one of the most backwards things the Go community did was adopt "Make", it's so kludgey even as a pure command executor that I can't really take anyone seriously who argues for it's use. I'm not saying "Just" is a replacement, I don't know what is. Most of the arguments for using Make boil down to "I enjoy typing `make <something>`" and "you probably have it installed already?".
rcarmo 4y ago
As someone who _extensively_ uses Makefiles everywhere to speed up things (why bother remembering how to start a server in a particular language when “make serve” will work anywhere), I almost understand why this exists, but then I remember that make is available everywhere and has tab auto completion and I have to wonder why…
- chungy 4y ago
  Pretty much my reaction too. Seems like Make, reinvented.
  - TuringTest 4y ago
    Which is a good thing, as it supports a use case that Make wasn't made for.
    - chungy 4y ago
      What use case is that? I looked over the README, including the parts where it claims to do things Make can't (I don't agree with much of it). I remain unconvinced that it supports use cases Make can't.
      - TuringTest 4y ago
        It's not that Make can't work as a task launcher, it's that it's not designed as such. The simple fact that a build target isn't executed if the build file already exists, requiring a workaround to run it, points to the difference in purpose and philosophy. Those little details, together with the more modern design, accumulate to make Just a tool that is simpler to use for that purpose.
- stevenhuang 4y ago
  Yup. All anyone needs is to learn Make properly once, which can be done from following a simple guide like https://medium.com/stack-me-up/using-makefiles-the-right-way-a82091286950 https://medium.com/stack-me-up/using-makefiles-the-right-way...
akdor1154 4y ago
I've come across this a few times, it seems to cope very well with all the things I'm abusing Make to do. I'm hesitant to add niche tooling requirements to my projects though. Can anyone comment with their experience using this? (in particular the social ramifications)
- rcarmo 4y ago
  Well, let me put it this way: I never use a tool that isn’t bundled with the OS or the runtime I’m developing for, because I don’t want my environment to be a special snowflake (and I develop stuff on Linux and macOS, with essentially the same CLI tools).
  - rgoulter 4y ago
    Using the Nix package manager solves these problems. With nix, all sorts of niche packages are available, so installing just isn't difficult. (& packages nix installed only go in /nix/store, so the filesystem isn't messed up). If you want the same programs (the same version of programs, even) across different Linux distributions, and macOS, nix is the best tool for that. If you're worried about your environment being an unreproducible snowflake, nix's main advertised feature is reproducing package installation. Although, yeah, Nix suffer the same cost of "1 more niche thing to install".
    - kaba0 4y ago
      Direnv is the real QOL improvement. You just add a .envrc file, write a flake.nix file listing your dependencies and anytime you enter a project directory you have every project dependency/tooling instantly available, but they otherwise don’t bother you at all.
  - kaba0 4y ago
    Are you writing everything in sh?
0cf8612b2e1e 4y ago
What would it take to unseat Make? Make is installed everywhere, so it is really hard for me to justify leaning on new tooling. Make is ok, but it has enough deficiencies that I longingly look at tools like this.
- rodarmor 4y ago
  I definitely don't think Just will ever unseat Make. Just doesn't have file-based dependencies, so it's not a build system, just a command runner. As far as unseating Make as a command runner, I think that might just take Just being available in more places, since one of the main advantages of Make that many users cite is that it's available everywhere. Just is already available in a lot of package repos, but not all of them. Finally packaging Just for Debian[0] would help a lot. [0] https://github.com/casey/just/issues/429 https://github.com/casey/just/issues/429
simonw 4y ago
I've been using this for about six months now and I absolutely love it. Make never stuck for me - I couldn't quite get it to fit inside my head. Just has the exact set of features I want. Here's one example of one of my Justfiles: https://github.com/simonw/sqlite-utils/blob/fc221f9b62ed8624b1d2098e564f525c84497969/Justfile https://github.com/simonw/sqlite-utils/blob/fc221f9b62ed8624... - documented here: https://sqlite-utils.datasette.io/en/stable/contributing.html#using-just-and-pipenv https://sqlite-utils.datasette.io/en/stable/contributing.htm... I also wrote about using Just with Django in this TIL: https://til.simonwillison.net/django/just-with-django https://til.simonwillison.net/django/just-with-django
- rcarmo 4y ago
  You don’t need to use all of make’s features (I’ve been using it for something like 30 years and still can’t fathom sets of it). But TBH I just don’t see anything in those Justfiles I couldn’t do with make without needing to do anything special…
  - 0cf8612b2e1e 4y ago
    Getting the list of make targets by default is pretty nifty. As is not having to preface everything with PHONY. Do any of these make alternatives reinvent the paradigm? No, but they do offer some quality of life improvements I wish were within reach without jumping through hoops.
    - enriquto 4y ago
      What's the problem with ".PHONY" ? Just the name ? Would it be alright for you if it had a different name, like "INTERFACE" or "COMMANDS", or "NOFILE" ? I never thought about .PHONY as a workaround to anything. Just a slightly unnecessary annotation that you may add to the makefile if you want to be pedantically correct.
  - simonw 4y ago
    I'm sure you can do that stuff with Make. Like I said though, I have tried and failed to get Make to stick for me in the past. Maybe it's just that my brain has such a strong negative reaction to that PHONY hack that I was never able to get past it. Maybe Just's tagline should be "it's Make, but you don't have to remember what PHONY means".
user3939382 4y ago
These issues are part of my daily work. I’ve started converting the make targets/commands to shell scripts because the hacks and ugliness that you have to do to provide make with arguments isn’t worth it. It seems like the more advanced shell features you want to use in a makefile, the more make gets in your way. Not that I fault it. It’s supposed to be for making programs hence the name. We’re abusing it by turning into a script collection.
tejtm 4y ago
I do love me some make, and have since forever. but we do have to look for a successor as cleaning out all of make's historical baggage would be a disservice to too many (really any is too many). If you are not sure of what I am talking about, try typing `make -p` those builtin rules can be disabled if you are not building ancient artifacts but that we have to is why one of these work-a-likes is going to win some day.
hestefisk 4y ago
How is this different to a shell script / command alias?
- simonw 4y ago
  You can easily create a separate Justfile for every one of your projects. Shell aliases are generally global, not project-specific.
- jacurtis 4y ago
  This ships with your project and is project specific. Sure you could accomplish something similar with direnv to maintain the project-level scope. But Just makes it more explicit.
  - rgoulter 4y ago
    Right. I think looking at the features, you see "minor quality of life UX improvements", and it's not mind-blowing. (just commands implicitly run with the workdir of the justfile, just --choose uses fzf, soft tabs not required, etc.). The effect does end up being a nicer tool to use.
politician 4y ago
I use github.com/TekWizely/run for this use case. It's a robust way to build one-off command-line "APIs" for managing projects and documenting processes. I deploy it in production environments along with application-specific Runfiles for devops. It makes life a lot easier when onboarding new folks, or for remembering how to do something months later. I also use make, but limit it to just building software. All of my repos have a Runfile and a Makefile.
letmeinhere 4y ago
I like the idea of trying to rethink the Make interface, but it just seems like most projects could actually benefit from build targets (conditional execution based on file existence/age), even if it's not the first thing you need to automate. I don't want to give that up because PHONY is confusing.
Ameo 4y ago
Huge fan of just; I add a Justfile to pretty muc hevery new repo I create regardless of language or stack. My personal favorite feature is the ability to load environment variables from a `.env` file and set them for all commands run. Just have to add this to the top of your `Justfile` to make it happen: `set dotenv-load := true`
- efxhoy 4y ago
  > the ability to load environment variables from a `.env` file make can do that too. Put include .env export at the top of the Makefile. Works for me on GNU Make 3.81 on MacOS.
  - n8henrie 4y ago
    Thanks, I was just looking for a way to do this today! Looks like there are some caveats and a slightly different approach: https://unix.stackexchange.com/a/235254 https://unix.stackexchange.com/a/235254
cute_boi 4y ago
I have been using Just for 3 months and it is such a fantastic tool. I never looked back at make. I don't even look at npm scripts anymore. I love Just.
_jplc 4y ago
Tools like these are handy, for sure. Problem is: If you're collaborating in a project, then you're requiring a new dependency to be installed in everyone's machine. Stuff like `make` is already there, always. In my case, I assume everyone has Python 3 and include a `task` script using this template, which does something similar: https://gist.github.com/sirikon/d4327b6cc3de5cc244dbe5529d8f53ae https://gist.github.com/sirikon/d4327b6cc3de5cc244dbe5529d8f...
- nicoburns 4y ago
  I feel like this a pretty non-issue so long as you document both that the dependency is required, and how to install it. Just is much easier to install than Python!
  - _jplc 4y ago
    Is it? Python is basically everywhere, and if it's not already installed, your package manager has it ready. `apt install python3`, done. Also, with Python you have... Python, all the language's power to extend your scripts as needed. `Just` works with a shell like bash, and I pretty much prefer python for scripting. Bash scripts get complicated very quickly.
    - nicoburns 4y ago
      It does, but you probably don't want to use the Python from your package manager. That tends to cause all sorts of problems when you need a newer version or different versions for different projects down the line. This is especially the case if you intend to use any packages in your python code. Managing dependencies in python gets complex quickly. Your package manager likely also has just: https://github.com/casey/just#packages https://github.com/casey/just#packages.
jacobsenscott 4y ago
I use https://github.com/davetron5000/gli https://github.com/davetron5000/gli for this, since I work in ruby. Adding something like just or gli to your project is a huge win. Every dev can just `just update_db` to refresh their dev db, `just update_secrets` to update dev secrets. Whatever. So much better than putting snippets in a wiki or whatever. I like gli because it gives you subcommands, like `gli database refresh` etc.
llIIllIIllIIl 4y ago
Great project, 40 years late though.
garganzol 4y ago
Nah, just does not support automatic parallelization of the dependency graph. This is a deal breaker for me. Also I'm not a huge fun of a yet another built-in language that tries to mimic a full-featured programming language.
- psuedo_uuh 4y ago
  I assume u write everything in assembly then
JakaJancar 4y ago
Competition: https://pydoit.org/ https://pydoit.org/ I've been using it for a while and it's pretty flexible: - dependencies - parallelism - programmatically generated tasks (since the config file is just a Python file) - "udf" to specify when a task is up-to-date and can be skipped
- cortesoft 4y ago
  It seems to me like the selling point of this tool is that it is language agnostic - you don't have to write all your jobs in Python. There are a lot of language specific tools like this. I love Ruby's rake.
  - JakaJancar 4y ago
    pydoit is language agnostic (apart from using python for your configuration, but you'll need to use something)
  - xigoi 4y ago
    > It seems to me like the selling point of this tool is that it is language agnostic How is having to use Python different from having to use the Justfile language?
zackees 4y ago
I'm still waiting on a tool that installs an activate.sh/activate.bat file that will bootstrap the tool when it's not installed, and then load up the environmental variables so that clean/build/deploy/test becomes active. Manually installing stuff sucks. It should be cross platform, automated and local by default whenever possible.
elliotshep 4y ago
If you don't have enough yaml in your life, https://taskfile.dev/ https://taskfile.dev/ is excellent.
rochak 4y ago
My personal favorite for small projects is invoke: https://www.pyinvoke.org/ https://www.pyinvoke.org/. I prefer it with python because it is just another lean dependency I can directly install along with other dependencies. Works pretty well unless you wanna chain and run long shell commands.
- jsmeaton 4y ago
  My biggest pet peeve with pyinvoke is that you can’t pass arbitrary arguments through to the underlying task. For something like invoking pytest you need to replicate the arguments you use in the task definition.
  - rochak 4y ago
    Yup! I totally get that as I ran into it the first time I used pyinvoke. I got around this limitation by using pyinvoke to just specify the tasks, their arguments and what other tasks they rely on, and let the tasks that share arguments delegate their core to the common function. It is an inconvenience, so I was planning on contributing this missing feature upstream to the library.
peteatphylum 4y ago
Another huge fan of just, here. I love that it's installable with a one-liner and I've added this as an option to my dotfile setup. I'm done trying to cast spells at Make
AviationAtom 4y ago
That README is quite the novel. I guess I prefer overly verbose documentation to under though.
deleted 4y ago
[deleted]
paxys 4y ago
This looks incredibly useful. Random question since I couldn't find it in the README – can i define a recipe (or recipe list) in a common location in my home folder and then use them from anywhere? While having a per project config is the intended use case, I'd also like a bunch of global ones.
- JuniperMesos 4y ago
  See https://github.com/casey/just/pull/1470 https://github.com/casey/just/pull/1470
  - paxys 4y ago
    Not exactly relevant. You'd still need a justfile in any location you are running the command from even after this change.
- rgoulter 4y ago
  The just manual describes some ways to do this. https://just.systems/man/en/chapter_65.html https://just.systems/man/en/chapter_65.html The intended way seems to be to invoke just with explicit --justfile and --workdir arguments, and wrap that invocation with a shell alias/function.
xaduha 4y ago
Make is firmly in a category of 'better the devil you know' for me. Not that I deeply know it, I use just a subset of it anyway and for that it's fine. If there's was a short Make: The Good Parts O'Reilly book, then I would probably read it.
davidpfarrell 4y ago
A tool that I created in the same category: RUN : A Task runner that helps you easily manage and invoke small scripts and wrappers * https://github.com/TekWizely/run https://github.com/TekWizely/run Do you find yourself using tools like make to manage non-build-related scripts? Build tools are great, but they are not optimized for general script management. Run aims to be better at managing small scripts and wrappers, while incorporating a familiar make-like syntax. Some features: * Auto generates command list * Auto generates help for commands * Supports defining command-line arguments, which are presented in help text * Can be composed via includes * Each command can define its own shell (or even python, etc) If you're interested in task runners, I hope you'll take a look!
throwawaaarrgh 4y ago
Make is acceptable for running arbitrary bunches of commands. For anything grander, I just write shell scripts that call shell scripts. Once you know shell well, it's very easy to throw together a simple build system. For a complex build system I'd go find a complex build tool.
gregwebs 4y ago
Just is designed for running commands, make is designed for tracking dependencies. I use them both in the same project calling each other if need be: there isn’t a competition here.
- FireInsight 4y ago
  If already you use make, I don't see a reason to also use just, since you can just do what just does with make.
  - gregwebs 4y ago
    That’s often pragmatic if you have 3-4 commands. But when you have more eventually you’ll end up with a cluttered Makefile and a poor command runner. just -l shows all the tasks available. Just commands take cli arguments instead of being forced to use environment variables which are susceptible to typos, etc. I can write a 3 line script in normal bash syntax instead of slightly different make syntax and then easily move it to be a separate shell script when it gets bigger.
domenukk 4y ago
There is also cargo make which, at least in rust land, serves a similar purpose. https://github.com/sagiegurari/cargo-make https://github.com/sagiegurari/cargo-make I ended up using it over just because it felt easier to use cross platform, and toml seemed like a right choice
voxelghost 4y ago
My dream is that git will add basic build capabilities
- xigoi 4y ago
  That would go against the Unix philosophy.
l0b0 4y ago
If you're going to use it like Make without the build system parts, why not just have a directory of tiny scripts? More portable than either, the only boilerplate is a shebang line, and you can use static analysis tools (shellcheck), formatters (shfmt) and the like. Take the example they've screenshotted in the readme[1]: alias b := build host := `uname -a` # build main build: cc *.c -o main # test everything test-all: build ./test --all # run a specific test test TEST: build ./test --test {{TEST}} The equivalent would just be something like the following: build.bash: #!/usr/bin/env bash set -o errexit cc *.c -o main test-all.bash: #!/usr/bin/env bash set -o errexit "$(dirname "${BASH_SOURCE[0]}")/build.bash" ./test --all test.bash: #!/usr/bin/env bash set -o errexit "$(dirname "${BASH_SOURCE[0]}")/build.bash" ./test --test "$@" If you want to get really fancy you could make a common.bash with safety pragmas and things like the host string. [1]: https://github.com/casey/just/blob/master/examples/screenshot.just https://github.com/casey/just/blob/master/examples/screensho...
- pletnes 4y ago
  Just runs fine on windows, too, which most people seem to miss. Bash is not always available, make even less so.
  - oso2k 4y ago
    As matter of practice, I always install git-bash or MinGW or CygWin on my Windows boxes. There's only one instance I've found where these solutions were not sufficient for my uses cases and it was an admittedly horrible corner case where a customer's network forced me to not "do the right thing(tm)".
    - pletnes 4y ago
      Having tried all 3, I’ll warmly recommend WSL2 instead, which is basically linux. But many people do work on windows, even write software for it. While I’m in your Linux based corner, some people aren’t, and it’s nice to share a task runner with them. Last time I checked, git bash doesn’t ship make, either.
kjgkjhfkjf 4y ago
This is actually very different than `make`, since it will always run the tasks even if their inputs haven't changed[0]. It's a bit bizarre to me that their example involves building code, since that application generally benefits from this "idiosyncratic" behavior of `make`. You probably would want the behavior of `make` for the `test` command too, to avoid running potentially time-consuming tests unnecessarily. Bazel caches test results to avoid this, for example. [0] https://github.com/casey/just#what-are-the-idiosyncrasies-of-make-that-just-avoids https://github.com/casey/just#what-are-the-idiosyncrasies-of...
- kevingadd 4y ago
  Caching test results sounds like a horrible idea, since the test could rely on external state or dependencies that weren't checked. For example, if you're testing something that opens a socket.
  - kjgkjhfkjf 4y ago
    Many folks believe that builds and tests should ideally be "hermetic", and not depend on external state. This can make tests more robust, and facilitates tasks such as bisecting to identify the cause of regressions.
    - kevingadd 4y ago
      I'm a big fan of fast, self-contained hermetic tests, but at the end of the day you should be testing the actual behavior of your software. This means all your dependencies should be versioned so you can bisect actual behavior, not mocked test behavior. I've also rarely ever touched software that is actually free of nondeterminism, so I am deeply skeptical of caching anything but the simplest test case. And those are fast.
      - kjgkjhfkjf 4y ago
        You should avoid flaky tests. They slow down presubmits and make it hard to do bisections.
jbverschoor 4y ago
It’s funny how things evolve. This is clearly something similar to make. All sorts of tools use xxxxfile for their config. But the tool “make” it’s actually short for “make file”. That’s what make does, it makes files (and has modified date dependencies)
- kaba0 4y ago
  Well, it just make files. But it is quite clearly a revamped make.
rsanheim 4y ago
I dig the general idea, but question the value add over a directory of `scripts` that follow sane conventions (ie `script/test`, `script/build` etc). Is the main thing that you can do `just -l` to see available commands? I have never really reached for `make` when I've had a choice, as I've done mostly ruby, JS, or java where you have more sane, humane tools (i.e. Rake, Yarn, Maven though that one is never fun). My general approach is every repo should have something that follows https://github.com/github/scripts-to-rule-them-all https://github.com/github/scripts-to-rule-them-all, written in sh (maybe bash, its 2023), linted with shellcheck. When you need something fancy Rake is great or grab some nice bash command line helper and source it from all your scripts. Is a command listing really worth another dependency over what you get from `ls script` or `cat script/README` ?
- dnsco 4y ago
  I've migrated from a ./scripts directory to a justfile and greatly appreciate the concision and modularity. I understand and have tried source'ing common bash files, but have never managed to make it feel quite right. ```just``` has bought my current project a lot of time until we replace it with some behemoth like bazel.
bilekas 4y ago
This looks great and the first time I've come across it.. One thing I notice straight away is the incredible amount and quality of the documentation!
shashashasha___ 4y ago
For rust cargo-make is also pretty good and got lots of cool rust specific features https://github.com/sagiegurari/cargo-make https://github.com/sagiegurari/cargo-make (just is written in rust)
oakesm9 4y ago
Another simple tool similar to this is makesure[1]. It’s written in shell so the idea is you include makesure itself in your repo, which avoids needing to install another tool to run commands on your project. It’s very simple so isn’t good for everything, but works well as a simple command runner. [1] https://github.com/xonixx/makesure https://github.com/xonixx/makesure
- baldomo 4y ago
  Looks cool! Including the script in the project directory is the way, and I created on makesh[1] with that in mind. Since it's a submodule it can be easily pulled around with a repo and updated. Glad to see people are finally going back to ahell scripts since they are very ergonomic and with a little portability in mind, they can be cross platform too. [1] https://github.com/Baldomo/makesh https://github.com/Baldomo/makesh
Dowwie 4y ago
Has anyone got a just recipe for looping through commands using a list of strings as inputs?
gempir 4y ago
I don't see anything about including other Justfiles or just generally other file. Might be nice to split up huge projects. The alternative Taskfile can do that https://taskfile.dev/usage/#including-other-taskfiles https://taskfile.dev/usage/#including-other-taskfiles
- jkrubin 4y ago
  That looks cool but I fundamentally hate yaml so it’s a no go. I would rather lose my hair screwing with a makefile like thing than add more yaml to my day to day; I currently say “I hate yaml” at least 4 times a day. If it’s not too much trouble and I don’t need comments I just write json as yaml.
  - andreynering 4y ago
    What makes you hate YAML so much? What alternative would you suggest for a tool like this?
  - rochak 4y ago
    +1 YAML are a bane to my existence.
dusted 4y ago
Smells like alias just=make
pingwin 4y ago
I use make extensively for a company wide build system across most/all products. Normalized everything. Someone at the company introduced Just in their projects. I’ve used it quite a bit now, it’s great EXCEPT that you cannot include other Justfiles. So abstraction is impossible. If I want to implement something like a push feature, that has to be implemented everywhere, with no way to centrally update all projects.
- tucosan 4y ago
  Look at task instead. It's the superior project IMHO. https://taskfile.dev/ https://taskfile.dev/
- davidpfarrell 4y ago
  I invite you take a look at Run, a similar tool that I maintain: * https://github.com/TekWizely/run https://github.com/TekWizely/run Support for including other Runfiles was recently introduced, with support for globbing and the ability to indicate if an error should be generated if no files are found.
_jcrossley 4y ago
Hey, this is really cool! Coincidentally I’ve been doing something really similar with `alias j=‘make -f ~/Makefile’` for a single giant makefile across multiple projects; I also combine it with fzf to allow fuzzy-searching for target names.
transportheap 4y ago
the just dev has questionable privacy view, used to copy all Justfiles on github - https://github.com/casey/just/issues/1163 https://github.com/casey/just/issues/1163 - https://github.com/casey/just/issues/503 https://github.com/casey/just/issues/503
- renewiltord 4y ago
  The issue appears to be that if you make a public Github repo, his bot will crawl it and add it to a repository of Justfiles for him to check against? That really isn't a privacy view in my mind. As soon as you add something to a public Github repo it is instantly indexed and made available on a bunch of (shady and legit) Github mirrors.

482 points by tnorthcutt 4y ago

It seems to me much nicer choice is https://taskfile.dev/ https://taskfile.dev/ Just doesn't seem to even support caching task results (by declaring inputs/outputs)?

xwowsersx 4y ago

The manual appears to be busted. The installation docs at https://just.systems/man/en/chapter_2.html#installation https://just.systems/man/en/chapter_2.html#installation just (ha) shows an empty page.

Jtsummers 4y ago
Try going to the subsections inside of Installation. https://just.systems/man/en/chapter_4.html https://just.systems/man/en/chapter_4.html
- xwowsersx 4y ago
  Ah thank you
JacobLinney 4y ago
I believe this is just due to how they're parsing the README.md on https://github.com/casey/just https://github.com/casey/just. (Though this should probably still be updated) The installation section has no direct body, but there are subheaders with the actual instructions. Ex. https://just.systems/man/en/chapter_3.html https://just.systems/man/en/chapter_3.html

velcrovan 4y ago

One of the listed benefits of just is "Recipes can be listed from the command line." There is a nice trick that gives makefiles this ability: http://marmelab.com/blog/2016/02/29/auto-documented-makefile.html http://marmelab.com/blog/2016/02/29/auto-documented-makefile... Adding .PHONY targets and so forth is a bit inelegant, but I can share a makefile with confidence that any Linux/Mac OS/BSD user can use it without needing additional software, and I will never have to worry about make becoming unavailable or no longer maintained. Just my personal opinion.

rcarmo 4y ago
Actually, I did a hack that does that too (this one is nicer, though). I can’t find mine offhand (too many makefiles), but it is also a Makefile target that runs grep -B1 on the Makefile itself and spits out each target’s name and the comment I usually add to it… And my Makefile template uses .env files too… I think I cover most of the list in my day-to-day use.
- oso2k 4y ago
  That works well if you have targets with simple comments that are directly above the target and don't extend beyond a single line. It may be important to provide several lines of help. This gist has other solutions as well: https://gist.github.com/prwhite/8168133 https://gist.github.com/prwhite/8168133
codetrotter 4y ago
> I can share a makefile with confidence that any Linux/Mac OS/BSD user can use it without needing additional software Makefile portability can be tricky. Especially if you try to do something fancy with the makefiles. GNU Make has features and syntax that the other Makes don’t. Likewise there are features and syntax that some Make programs have that GNU Make doesn’t.
deleted 4y ago
[deleted]
dijit 4y ago
> but I can share a makefile with confidence that any Linux/Mac OS/BSD can use it without needing any additional software I'm sure you're kidding, but in the case that you're not: Make portability is gross. We have ./configure steps precisely because Make is difficult w.r.t. portability, but even if that wasn't the case and you were just using make as a command executor: you still have enormous warts. Oh, and yeah, you'd need whatever additional software too. Be it: headers, linters, formatters, libraries or test suites that you've bundled. Valgrind is a popular make target, but "Make" does not bring in valgrind (for example). Honestly one of the most backwards things the Go community did was adopt "Make", it's so kludgey even as a pure command executor that I can't really take anyone seriously who argues for it's use. I'm not saying "Just" is a replacement, I don't know what is. Most of the arguments for using Make boil down to "I enjoy typing `make <something>`" and "you probably have it installed already?".

rcarmo 4y ago

As someone who _extensively_ uses Makefiles everywhere to speed up things (why bother remembering how to start a server in a particular language when “make serve” will work anywhere), I almost understand why this exists, but then I remember that make is available everywhere and has tab auto completion and I have to wonder why…

chungy 4y ago
Pretty much my reaction too. Seems like Make, reinvented.
- TuringTest 4y ago
  Which is a good thing, as it supports a use case that Make wasn't made for.
  - chungy 4y ago
    What use case is that? I looked over the README, including the parts where it claims to do things Make can't (I don't agree with much of it). I remain unconvinced that it supports use cases Make can't.
    - TuringTest 4y ago
      It's not that Make can't work as a task launcher, it's that it's not designed as such. The simple fact that a build target isn't executed if the build file already exists, requiring a workaround to run it, points to the difference in purpose and philosophy. Those little details, together with the more modern design, accumulate to make Just a tool that is simpler to use for that purpose.
stevenhuang 4y ago
Yup. All anyone needs is to learn Make properly once, which can be done from following a simple guide like https://medium.com/stack-me-up/using-makefiles-the-right-way-a82091286950 https://medium.com/stack-me-up/using-makefiles-the-right-way...

akdor1154 4y ago

I've come across this a few times, it seems to cope very well with all the things I'm abusing Make to do. I'm hesitant to add niche tooling requirements to my projects though. Can anyone comment with their experience using this? (in particular the social ramifications)

rcarmo 4y ago
Well, let me put it this way: I never use a tool that isn’t bundled with the OS or the runtime I’m developing for, because I don’t want my environment to be a special snowflake (and I develop stuff on Linux and macOS, with essentially the same CLI tools).
- rgoulter 4y ago
  Using the Nix package manager solves these problems. With nix, all sorts of niche packages are available, so installing just isn't difficult. (& packages nix installed only go in /nix/store, so the filesystem isn't messed up). If you want the same programs (the same version of programs, even) across different Linux distributions, and macOS, nix is the best tool for that. If you're worried about your environment being an unreproducible snowflake, nix's main advertised feature is reproducing package installation. Although, yeah, Nix suffer the same cost of "1 more niche thing to install".
  - kaba0 4y ago
    Direnv is the real QOL improvement. You just add a .envrc file, write a flake.nix file listing your dependencies and anytime you enter a project directory you have every project dependency/tooling instantly available, but they otherwise don’t bother you at all.
- kaba0 4y ago
  Are you writing everything in sh?

0cf8612b2e1e 4y ago

What would it take to unseat Make? Make is installed everywhere, so it is really hard for me to justify leaning on new tooling. Make is ok, but it has enough deficiencies that I longingly look at tools like this.

rodarmor 4y ago
I definitely don't think Just will ever unseat Make. Just doesn't have file-based dependencies, so it's not a build system, just a command runner. As far as unseating Make as a command runner, I think that might just take Just being available in more places, since one of the main advantages of Make that many users cite is that it's available everywhere. Just is already available in a lot of package repos, but not all of them. Finally packaging Just for Debian[0] would help a lot. [0] https://github.com/casey/just/issues/429 https://github.com/casey/just/issues/429

simonw 4y ago

I've been using this for about six months now and I absolutely love it. Make never stuck for me - I couldn't quite get it to fit inside my head. Just has the exact set of features I want. Here's one example of one of my Justfiles: https://github.com/simonw/sqlite-utils/blob/fc221f9b62ed8624b1d2098e564f525c84497969/Justfile https://github.com/simonw/sqlite-utils/blob/fc221f9b62ed8624... - documented here: https://sqlite-utils.datasette.io/en/stable/contributing.html#using-just-and-pipenv https://sqlite-utils.datasette.io/en/stable/contributing.htm... I also wrote about using Just with Django in this TIL: https://til.simonwillison.net/django/just-with-django https://til.simonwillison.net/django/just-with-django

rcarmo 4y ago
You don’t need to use all of make’s features (I’ve been using it for something like 30 years and still can’t fathom sets of it). But TBH I just don’t see anything in those Justfiles I couldn’t do with make without needing to do anything special…
- 0cf8612b2e1e 4y ago
  Getting the list of make targets by default is pretty nifty. As is not having to preface everything with PHONY. Do any of these make alternatives reinvent the paradigm? No, but they do offer some quality of life improvements I wish were within reach without jumping through hoops.
  - enriquto 4y ago
    What's the problem with ".PHONY" ? Just the name ? Would it be alright for you if it had a different name, like "INTERFACE" or "COMMANDS", or "NOFILE" ? I never thought about .PHONY as a workaround to anything. Just a slightly unnecessary annotation that you may add to the makefile if you want to be pedantically correct.
- simonw 4y ago
  I'm sure you can do that stuff with Make. Like I said though, I have tried and failed to get Make to stick for me in the past. Maybe it's just that my brain has such a strong negative reaction to that PHONY hack that I was never able to get past it. Maybe Just's tagline should be "it's Make, but you don't have to remember what PHONY means".

user3939382 4y ago

These issues are part of my daily work. I’ve started converting the make targets/commands to shell scripts because the hacks and ugliness that you have to do to provide make with arguments isn’t worth it. It seems like the more advanced shell features you want to use in a makefile, the more make gets in your way. Not that I fault it. It’s supposed to be for making programs hence the name. We’re abusing it by turning into a script collection.

tejtm 4y ago

I do love me some make, and have since forever. but we do have to look for a successor as cleaning out all of make's historical baggage would be a disservice to too many (really any is too many). If you are not sure of what I am talking about, try typing `make -p` those builtin rules can be disabled if you are not building ancient artifacts but that we have to is why one of these work-a-likes is going to win some day.

hestefisk 4y ago

How is this different to a shell script / command alias?

simonw 4y ago
You can easily create a separate Justfile for every one of your projects. Shell aliases are generally global, not project-specific.
jacurtis 4y ago
This ships with your project and is project specific. Sure you could accomplish something similar with direnv to maintain the project-level scope. But Just makes it more explicit.
- rgoulter 4y ago
  Right. I think looking at the features, you see "minor quality of life UX improvements", and it's not mind-blowing. (just commands implicitly run with the workdir of the justfile, just --choose uses fzf, soft tabs not required, etc.). The effect does end up being a nicer tool to use.

politician 4y ago

I use github.com/TekWizely/run for this use case. It's a robust way to build one-off command-line "APIs" for managing projects and documenting processes. I deploy it in production environments along with application-specific Runfiles for devops. It makes life a lot easier when onboarding new folks, or for remembering how to do something months later. I also use make, but limit it to just building software. All of my repos have a Runfile and a Makefile.

letmeinhere 4y ago

I like the idea of trying to rethink the Make interface, but it just seems like most projects could actually benefit from build targets (conditional execution based on file existence/age), even if it's not the first thing you need to automate. I don't want to give that up because PHONY is confusing.

Ameo 4y ago

Huge fan of just; I add a Justfile to pretty muc hevery new repo I create regardless of language or stack. My personal favorite feature is the ability to load environment variables from a `.env` file and set them for all commands run. Just have to add this to the top of your `Justfile` to make it happen: `set dotenv-load := true`

efxhoy 4y ago
> the ability to load environment variables from a `.env` file make can do that too. Put include .env export at the top of the Makefile. Works for me on GNU Make 3.81 on MacOS.
- n8henrie 4y ago
  Thanks, I was just looking for a way to do this today! Looks like there are some caveats and a slightly different approach: https://unix.stackexchange.com/a/235254 https://unix.stackexchange.com/a/235254

cute_boi 4y ago

I have been using Just for 3 months and it is such a fantastic tool. I never looked back at make. I don't even look at npm scripts anymore. I love Just.

_jplc 4y ago

Tools like these are handy, for sure. Problem is: If you're collaborating in a project, then you're requiring a new dependency to be installed in everyone's machine. Stuff like `make` is already there, always. In my case, I assume everyone has Python 3 and include a `task` script using this template, which does something similar: https://gist.github.com/sirikon/d4327b6cc3de5cc244dbe5529d8f53ae https://gist.github.com/sirikon/d4327b6cc3de5cc244dbe5529d8f...

nicoburns 4y ago
I feel like this a pretty non-issue so long as you document both that the dependency is required, and how to install it. Just is much easier to install than Python!
- _jplc 4y ago
  Is it? Python is basically everywhere, and if it's not already installed, your package manager has it ready. `apt install python3`, done. Also, with Python you have... Python, all the language's power to extend your scripts as needed. `Just` works with a shell like bash, and I pretty much prefer python for scripting. Bash scripts get complicated very quickly.
  - nicoburns 4y ago
    It does, but you probably don't want to use the Python from your package manager. That tends to cause all sorts of problems when you need a newer version or different versions for different projects down the line. This is especially the case if you intend to use any packages in your python code. Managing dependencies in python gets complex quickly. Your package manager likely also has just: https://github.com/casey/just#packages https://github.com/casey/just#packages.

jacobsenscott 4y ago

I use https://github.com/davetron5000/gli https://github.com/davetron5000/gli for this, since I work in ruby. Adding something like just or gli to your project is a huge win. Every dev can just `just update_db` to refresh their dev db, `just update_secrets` to update dev secrets. Whatever. So much better than putting snippets in a wiki or whatever. I like gli because it gives you subcommands, like `gli database refresh` etc.

llIIllIIllIIl 4y ago

Great project, 40 years late though.

garganzol 4y ago

Nah, just does not support automatic parallelization of the dependency graph. This is a deal breaker for me. Also I'm not a huge fun of a yet another built-in language that tries to mimic a full-featured programming language.

psuedo_uuh 4y ago
I assume u write everything in assembly then

JakaJancar 4y ago

Competition: https://pydoit.org/ https://pydoit.org/ I've been using it for a while and it's pretty flexible: - dependencies - parallelism - programmatically generated tasks (since the config file is just a Python file) - "udf" to specify when a task is up-to-date and can be skipped

cortesoft 4y ago
It seems to me like the selling point of this tool is that it is language agnostic - you don't have to write all your jobs in Python. There are a lot of language specific tools like this. I love Ruby's rake.
- JakaJancar 4y ago
  pydoit is language agnostic (apart from using python for your configuration, but you'll need to use something)
- xigoi 4y ago
  > It seems to me like the selling point of this tool is that it is language agnostic How is having to use Python different from having to use the Justfile language?

zackees 4y ago

I'm still waiting on a tool that installs an activate.sh/activate.bat file that will bootstrap the tool when it's not installed, and then load up the environmental variables so that clean/build/deploy/test becomes active. Manually installing stuff sucks. It should be cross platform, automated and local by default whenever possible.

elliotshep 4y ago

If you don't have enough yaml in your life, https://taskfile.dev/ https://taskfile.dev/ is excellent.

rochak 4y ago

My personal favorite for small projects is invoke: https://www.pyinvoke.org/ https://www.pyinvoke.org/. I prefer it with python because it is just another lean dependency I can directly install along with other dependencies. Works pretty well unless you wanna chain and run long shell commands.

jsmeaton 4y ago
My biggest pet peeve with pyinvoke is that you can’t pass arbitrary arguments through to the underlying task. For something like invoking pytest you need to replicate the arguments you use in the task definition.
- rochak 4y ago
  Yup! I totally get that as I ran into it the first time I used pyinvoke. I got around this limitation by using pyinvoke to just specify the tasks, their arguments and what other tasks they rely on, and let the tasks that share arguments delegate their core to the common function. It is an inconvenience, so I was planning on contributing this missing feature upstream to the library.

peteatphylum 4y ago

Another huge fan of just, here. I love that it's installable with a one-liner and I've added this as an option to my dotfile setup. I'm done trying to cast spells at Make

AviationAtom 4y ago

That README is quite the novel. I guess I prefer overly verbose documentation to under though.

deleted 4y ago

[deleted]

paxys 4y ago

This looks incredibly useful. Random question since I couldn't find it in the README – can i define a recipe (or recipe list) in a common location in my home folder and then use them from anywhere? While having a per project config is the intended use case, I'd also like a bunch of global ones.

JuniperMesos 4y ago
See https://github.com/casey/just/pull/1470 https://github.com/casey/just/pull/1470
- paxys 4y ago
  Not exactly relevant. You'd still need a justfile in any location you are running the command from even after this change.
rgoulter 4y ago
The just manual describes some ways to do this. https://just.systems/man/en/chapter_65.html https://just.systems/man/en/chapter_65.html The intended way seems to be to invoke just with explicit --justfile and --workdir arguments, and wrap that invocation with a shell alias/function.

xaduha 4y ago

Make is firmly in a category of 'better the devil you know' for me. Not that I deeply know it, I use just a subset of it anyway and for that it's fine. If there's was a short Make: The Good Parts O'Reilly book, then I would probably read it.

davidpfarrell 4y ago

A tool that I created in the same category: RUN : A Task runner that helps you easily manage and invoke small scripts and wrappers * https://github.com/TekWizely/run https://github.com/TekWizely/run Do you find yourself using tools like make to manage non-build-related scripts? Build tools are great, but they are not optimized for general script management. Run aims to be better at managing small scripts and wrappers, while incorporating a familiar make-like syntax. Some features: * Auto generates command list * Auto generates help for commands * Supports defining command-line arguments, which are presented in help text * Can be composed via includes * Each command can define its own shell (or even python, etc) If you're interested in task runners, I hope you'll take a look!

throwawaaarrgh 4y ago

Make is acceptable for running arbitrary bunches of commands. For anything grander, I just write shell scripts that call shell scripts. Once you know shell well, it's very easy to throw together a simple build system. For a complex build system I'd go find a complex build tool.

gregwebs 4y ago

Just is designed for running commands, make is designed for tracking dependencies. I use them both in the same project calling each other if need be: there isn’t a competition here.

FireInsight 4y ago
If already you use make, I don't see a reason to also use just, since you can just do what just does with make.
- gregwebs 4y ago
  That’s often pragmatic if you have 3-4 commands. But when you have more eventually you’ll end up with a cluttered Makefile and a poor command runner. just -l shows all the tasks available. Just commands take cli arguments instead of being forced to use environment variables which are susceptible to typos, etc. I can write a 3 line script in normal bash syntax instead of slightly different make syntax and then easily move it to be a separate shell script when it gets bigger.

domenukk 4y ago

There is also cargo make which, at least in rust land, serves a similar purpose. https://github.com/sagiegurari/cargo-make https://github.com/sagiegurari/cargo-make I ended up using it over just because it felt easier to use cross platform, and toml seemed like a right choice

voxelghost 4y ago

My dream is that git will add basic build capabilities

xigoi 4y ago
That would go against the Unix philosophy.

l0b0 4y ago

If you're going to use it like Make without the build system parts, why not just have a directory of tiny scripts? More portable than either, the only boilerplate is a shebang line, and you can use static analysis tools (shellcheck), formatters (shfmt) and the like. Take the example they've screenshotted in the readme[1]: alias b := build host := `uname -a` # build main build: cc *.c -o main # test everything test-all: build ./test --all # run a specific test test TEST: build ./test --test {{TEST}} The equivalent would just be something like the following: build.bash: #!/usr/bin/env bash set -o errexit cc *.c -o main test-all.bash: #!/usr/bin/env bash set -o errexit "$(dirname "${BASH_SOURCE[0]}")/build.bash" ./test --all test.bash: #!/usr/bin/env bash set -o errexit "$(dirname "${BASH_SOURCE[0]}")/build.bash" ./test --test "$@" If you want to get really fancy you could make a common.bash with safety pragmas and things like the host string. [1]: https://github.com/casey/just/blob/master/examples/screenshot.just https://github.com/casey/just/blob/master/examples/screensho...

pletnes 4y ago
Just runs fine on windows, too, which most people seem to miss. Bash is not always available, make even less so.
- oso2k 4y ago
  As matter of practice, I always install git-bash or MinGW or CygWin on my Windows boxes. There's only one instance I've found where these solutions were not sufficient for my uses cases and it was an admittedly horrible corner case where a customer's network forced me to not "do the right thing(tm)".
  - pletnes 4y ago
    Having tried all 3, I’ll warmly recommend WSL2 instead, which is basically linux. But many people do work on windows, even write software for it. While I’m in your Linux based corner, some people aren’t, and it’s nice to share a task runner with them. Last time I checked, git bash doesn’t ship make, either.

kjgkjhfkjf 4y ago

This is actually very different than `make`, since it will always run the tasks even if their inputs haven't changed[0]. It's a bit bizarre to me that their example involves building code, since that application generally benefits from this "idiosyncratic" behavior of `make`. You probably would want the behavior of `make` for the `test` command too, to avoid running potentially time-consuming tests unnecessarily. Bazel caches test results to avoid this, for example. [0] https://github.com/casey/just#what-are-the-idiosyncrasies-of-make-that-just-avoids https://github.com/casey/just#what-are-the-idiosyncrasies-of...

kevingadd 4y ago
Caching test results sounds like a horrible idea, since the test could rely on external state or dependencies that weren't checked. For example, if you're testing something that opens a socket.
- kjgkjhfkjf 4y ago
  Many folks believe that builds and tests should ideally be "hermetic", and not depend on external state. This can make tests more robust, and facilitates tasks such as bisecting to identify the cause of regressions.
  - kevingadd 4y ago
    I'm a big fan of fast, self-contained hermetic tests, but at the end of the day you should be testing the actual behavior of your software. This means all your dependencies should be versioned so you can bisect actual behavior, not mocked test behavior. I've also rarely ever touched software that is actually free of nondeterminism, so I am deeply skeptical of caching anything but the simplest test case. And those are fast.
    - kjgkjhfkjf 4y ago
      You should avoid flaky tests. They slow down presubmits and make it hard to do bisections.

jbverschoor 4y ago

It’s funny how things evolve. This is clearly something similar to make. All sorts of tools use xxxxfile for their config. But the tool “make” it’s actually short for “make file”. That’s what make does, it makes files (and has modified date dependencies)

kaba0 4y ago
Well, it just make files. But it is quite clearly a revamped make.

rsanheim 4y ago

I dig the general idea, but question the value add over a directory of `scripts` that follow sane conventions (ie `script/test`, `script/build` etc). Is the main thing that you can do `just -l` to see available commands? I have never really reached for `make` when I've had a choice, as I've done mostly ruby, JS, or java where you have more sane, humane tools (i.e. Rake, Yarn, Maven though that one is never fun). My general approach is every repo should have something that follows https://github.com/github/scripts-to-rule-them-all https://github.com/github/scripts-to-rule-them-all, written in sh (maybe bash, its 2023), linted with shellcheck. When you need something fancy Rake is great or grab some nice bash command line helper and source it from all your scripts. Is a command listing really worth another dependency over what you get from `ls script` or `cat script/README` ?

dnsco 4y ago
I've migrated from a ./scripts directory to a justfile and greatly appreciate the concision and modularity. I understand and have tried source'ing common bash files, but have never managed to make it feel quite right. ```just``` has bought my current project a lot of time until we replace it with some behemoth like bazel.

bilekas 4y ago

This looks great and the first time I've come across it.. One thing I notice straight away is the incredible amount and quality of the documentation!

shashashasha___ 4y ago

For rust cargo-make is also pretty good and got lots of cool rust specific features https://github.com/sagiegurari/cargo-make https://github.com/sagiegurari/cargo-make (just is written in rust)

oakesm9 4y ago

Another simple tool similar to this is makesure[1]. It’s written in shell so the idea is you include makesure itself in your repo, which avoids needing to install another tool to run commands on your project. It’s very simple so isn’t good for everything, but works well as a simple command runner. [1] https://github.com/xonixx/makesure https://github.com/xonixx/makesure

baldomo 4y ago
Looks cool! Including the script in the project directory is the way, and I created on makesh[1] with that in mind. Since it's a submodule it can be easily pulled around with a repo and updated. Glad to see people are finally going back to ahell scripts since they are very ergonomic and with a little portability in mind, they can be cross platform too. [1] https://github.com/Baldomo/makesh https://github.com/Baldomo/makesh

Dowwie 4y ago

Has anyone got a just recipe for looping through commands using a list of strings as inputs?

gempir 4y ago

I don't see anything about including other Justfiles or just generally other file. Might be nice to split up huge projects. The alternative Taskfile can do that https://taskfile.dev/usage/#including-other-taskfiles https://taskfile.dev/usage/#including-other-taskfiles

jkrubin 4y ago
That looks cool but I fundamentally hate yaml so it’s a no go. I would rather lose my hair screwing with a makefile like thing than add more yaml to my day to day; I currently say “I hate yaml” at least 4 times a day. If it’s not too much trouble and I don’t need comments I just write json as yaml.
- andreynering 4y ago
  What makes you hate YAML so much? What alternative would you suggest for a tool like this?
- rochak 4y ago
  +1 YAML are a bane to my existence.

dusted 4y ago

Smells like alias just=make

pingwin 4y ago

I use make extensively for a company wide build system across most/all products. Normalized everything. Someone at the company introduced Just in their projects. I’ve used it quite a bit now, it’s great EXCEPT that you cannot include other Justfiles. So abstraction is impossible. If I want to implement something like a push feature, that has to be implemented everywhere, with no way to centrally update all projects.

tucosan 4y ago
Look at task instead. It's the superior project IMHO. https://taskfile.dev/ https://taskfile.dev/
davidpfarrell 4y ago
I invite you take a look at Run, a similar tool that I maintain: * https://github.com/TekWizely/run https://github.com/TekWizely/run Support for including other Runfiles was recently introduced, with support for globbing and the ability to indicate if an error should be generated if no files are found.

_jcrossley 4y ago

Hey, this is really cool! Coincidentally I’ve been doing something really similar with `alias j=‘make -f ~/Makefile’` for a single giant makefile across multiple projects; I also combine it with fzf to allow fuzzy-searching for target names.

transportheap 4y ago

the just dev has questionable privacy view, used to copy all Justfiles on github - https://github.com/casey/just/issues/1163 https://github.com/casey/just/issues/1163 - https://github.com/casey/just/issues/503 https://github.com/casey/just/issues/503

renewiltord 4y ago
The issue appears to be that if you make a public Github repo, his bot will crawl it and add it to a repository of Justfiles for him to check against? That really isn't a privacy view in my mind. As soon as you add something to a public Github repo it is instantly indexed and made available on a bunch of (shady and legit) Github mirrors.