6 ms·

I mainly don't understand how Just is any better than a run/ directory full of executable shell scripts.

zwerdlds 2y ago
That works too. I've done both and I currently use Just because it collects the entrypoints to the project into a single file. This can provide an advantage where there's a bit of interdependence across your entrypoints. E.g: You have a docker container, you might be `run`ning it, `exec`ing it etc. from the same compose-file. So Just gives you the ability to link those shared commands within the same file. Once the entrypoints get too numerous you can either break them into scripts (I do this partially depending on the level of behavioral complexity in the script) or partition your justfiles and import them into a single master.
pdimitar 2y ago
If that works well for you, use it. I did that for 10+ years and got fed up with having to remember which names I gave to my scripts that month. I gradually evolved my views and that got reflected with the names of the scripts. `just` helped me finally move away from that. Now I have i.e. `just check` in projects in different languages that all do the same thing -- check types and/or run various linters. I can go in a directory and run `just check` and I know I have taken care to have all checks that I want in place. Similarly I can run `just test` and I know I'll have the test suite ran, again regardless of the programming language or framework. Absolutely nothing wrong with a directory full of scripts but I lost patience for having to scan what each does and moved away from them.
- lijok 2y ago
  > Now I have i.e. `just check` in projects in different languages that all do the same thing -- check types and/or run various linters. I can go in a directory and run `just check` and I know I have taken care to have all checks that I want in place. Similarly I can run `just test` and I know I'll have the test suite ran, again regardless of the programming language or framework. How is that different from having a scripts dir, and a script called `check` or `test`? How is `just -l` different to `ls scripts`?
  - pdimitar 2y ago
    I believe I already addressed that this is purely a matter of taste and convenience, not sure why you are not reading my comment and are asking for more. And it was already said: if you like it more, use it. Nobody is holding a gun to your head. And I even explained that I used that in the past and moved away from it.
    - akoboldfrying 2y ago
      I also haven't seen in your previous response how Just is better than a subdir with shell scripts named according to a convention. AFAICT, the productivity improvements you described came exclusively from using a consistent naming convention, not from Just. And since everyone's dev env supports subdirectories with shell scripts already, why not simply use that instead of requiring Just?
      - pdimitar 2y ago
        I got a down arrow on my comment that's your parent a minute before you responded. Coincidence, or you prefer to press it because you are not satisfied that I'm not your personal documentation agent? Finally and additionally as a response: because it's also all in one place. I don't want 10+ scripts. For the third time: I used bespoke scripts and found them not good enough compared to Just, now for even more reasons clearly spelled out. Sigh.
        akoboldfrying 2y ago
        I didn't downvote you, though I found your answer unhelpful. (I've now received 2 downvotes.) 10+ scripts with standard names ("clean", "test", "build", etc.) in a subdir added to $PATH seems to me to be easier to manage -- if the scripts are independent of each other. If they do have dependencies on each other, but the dependencies are "treelike" (meaning that for every target you might want to run, all of its transitive deps are reached via a unique path), it's still easier (than either make or Just) to have separate scripts, and turn each dep into a plain invocation at the top of each script. It's only when that approach starts to invoke deps multiple times (because it has become non-treelike) that either make or Just starts to offer an advantage. I think if you look at this with clear eyes, you'll see that 100% of the value you feel you're getting from Just is actually coming from the naming convention that Just nudged you towards.
- banku_brougham 2y ago
  yep just has good ergonomics for little things in my dev workflow
BeetleB 2y ago
Well, for one, your recipes can be in another language (e.g. Python). You can build complex recipes out of simpler ones. Sure, you could do that by creating a new shell script that calls other shell scripts, but then you're reinventing just. You don't need to be in the directory to run those scripts. I think a better question for you: What's the benefit of putting .PHONY recipes in Makefiles, when you could just have a directory full of shell scripts. If you find yourself using .PHONY recipes, then you already have a reason to use just.
- e12e 2y ago
  > Well, for one, your recipes can be in another language (e.g. Python). Surely this is true for stuff in a ./bin or ./scripts folder - binaries, python with shebang etc?
  - e12e 2y ago
    Ah, I see there's: https://just.systems/man/en/shebang-recipes.html https://just.systems/man/en/shebang-recipes.html Which could be done in shell, but typically rather be limited to oneliners (invoking awk) rather than piping a heredoc to an interpreter.
- akoboldfrying 2y ago
  > You don't need to be in the directory to run those scripts. There's already an easy way to solve this: $PATH. > I think a better question for you: What's the benefit of putting .PHONY recipes in Makefiles, when you could just have a directory full of shell scripts. If you find yourself using .PHONY recipes, then you already have a reason to use just. Well, I think it's the same question, rather than a better question. And the answer is yes, if all you need from make, now and in the future, is a set of .PHONY targets, then by all means just use shell scripts. make is used because often you need slightly more than this -- or you may do so tomorrow, and don't want to change the syntax you use to accomplish tasks.
  - BeetleB 2y ago
    > There's already an easy way to solve this: $PATH. I have 10 projects. Each with their own set of shell scripts. You want me (and all other developers) to pollute the $PATH with 10 directories? And then you have a namespace problem. I usually have a "test" recipe in my justfiles. The analog would be a test.sh file. But with your solution, it will have to be projA-test.sh and projB-test.sh. And if I dump them all into the $PATH, how do I quickly see the scripts relevant to a particular project?
brushfoot 2y ago
Agreed, particularly if you pipe to fzf. (For those who haven't used it, fzf is a fuzzy-searchable menu for the command line. You pipe lines of input to it, and it shows them in a menu. You start typing and it fuzzy searches the menu and selects the best match. Then you press Enter to pipe that out, or Tab for multi-select. It's fantastic.) I have convenience functions in my profile script that pipe different things to fzf...scripts, paths in the current directory to copy to the clipboard, etc. It's indispensable. Bonus: progressive enhancement. If someone doesn't have fzf/those convenience functions, it's just a directory with shell scripts, so they don't have to do anything special to use them.
slightwinder 2y ago
It's a different approach, none is better or worse, people simply have preferences. And all other features aside, it seems to be able to call commands from any subdirectory in a project, which is actually nice compared with a normal shell. I mean, you can replicate this with some lines of shellscripting, but not everyone seems to maintain an elaborated $BIN of personal tools.
gregwebs 2y ago
I do both. A script directory helps provide the underlying extensible tools. Just is a convenient ui for the most frequent dev use cases of a project.

That works too. I've done both and I currently use Just because it collects the entrypoints to the project into a single file. This can provide an advantage where there's a bit of interdependence across your entrypoints. E.g: You have a docker container, you might be `run`ning it, `exec`ing it etc. from the same compose-file. So Just gives you the ability to link those shared commands within the same file. Once the entrypoints get too numerous you can either break them into scripts (I do this partially depending on the level of behavioral complexity in the script) or partition your justfiles and import them into a single master.

pdimitar 2y ago

If that works well for you, use it. I did that for 10+ years and got fed up with having to remember which names I gave to my scripts that month. I gradually evolved my views and that got reflected with the names of the scripts. `just` helped me finally move away from that. Now I have i.e. `just check` in projects in different languages that all do the same thing -- check types and/or run various linters. I can go in a directory and run `just check` and I know I have taken care to have all checks that I want in place. Similarly I can run `just test` and I know I'll have the test suite ran, again regardless of the programming language or framework. Absolutely nothing wrong with a directory full of scripts but I lost patience for having to scan what each does and moved away from them.

lijok 2y ago
> Now I have i.e. `just check` in projects in different languages that all do the same thing -- check types and/or run various linters. I can go in a directory and run `just check` and I know I have taken care to have all checks that I want in place. Similarly I can run `just test` and I know I'll have the test suite ran, again regardless of the programming language or framework. How is that different from having a scripts dir, and a script called `check` or `test`? How is `just -l` different to `ls scripts`?
- pdimitar 2y ago
  I believe I already addressed that this is purely a matter of taste and convenience, not sure why you are not reading my comment and are asking for more. And it was already said: if you like it more, use it. Nobody is holding a gun to your head. And I even explained that I used that in the past and moved away from it.
  - akoboldfrying 2y ago
    I also haven't seen in your previous response how Just is better than a subdir with shell scripts named according to a convention. AFAICT, the productivity improvements you described came exclusively from using a consistent naming convention, not from Just. And since everyone's dev env supports subdirectories with shell scripts already, why not simply use that instead of requiring Just?
    - pdimitar 2y ago
      I got a down arrow on my comment that's your parent a minute before you responded. Coincidence, or you prefer to press it because you are not satisfied that I'm not your personal documentation agent? Finally and additionally as a response: because it's also all in one place. I don't want 10+ scripts. For the third time: I used bespoke scripts and found them not good enough compared to Just, now for even more reasons clearly spelled out. Sigh.
      - akoboldfrying 2y ago
        I didn't downvote you, though I found your answer unhelpful. (I've now received 2 downvotes.) 10+ scripts with standard names ("clean", "test", "build", etc.) in a subdir added to $PATH seems to me to be easier to manage -- if the scripts are independent of each other. If they do have dependencies on each other, but the dependencies are "treelike" (meaning that for every target you might want to run, all of its transitive deps are reached via a unique path), it's still easier (than either make or Just) to have separate scripts, and turn each dep into a plain invocation at the top of each script. It's only when that approach starts to invoke deps multiple times (because it has become non-treelike) that either make or Just starts to offer an advantage. I think if you look at this with clear eyes, you'll see that 100% of the value you feel you're getting from Just is actually coming from the naming convention that Just nudged you towards.
banku_brougham 2y ago
yep just has good ergonomics for little things in my dev workflow

BeetleB 2y ago

Well, for one, your recipes can be in another language (e.g. Python). You can build complex recipes out of simpler ones. Sure, you could do that by creating a new shell script that calls other shell scripts, but then you're reinventing just. You don't need to be in the directory to run those scripts. I think a better question for you: What's the benefit of putting .PHONY recipes in Makefiles, when you could just have a directory full of shell scripts. If you find yourself using .PHONY recipes, then you already have a reason to use just.

e12e 2y ago
> Well, for one, your recipes can be in another language (e.g. Python). Surely this is true for stuff in a ./bin or ./scripts folder - binaries, python with shebang etc?
- e12e 2y ago
  Ah, I see there's: https://just.systems/man/en/shebang-recipes.html https://just.systems/man/en/shebang-recipes.html Which could be done in shell, but typically rather be limited to oneliners (invoking awk) rather than piping a heredoc to an interpreter.
akoboldfrying 2y ago
> You don't need to be in the directory to run those scripts. There's already an easy way to solve this: $PATH. > I think a better question for you: What's the benefit of putting .PHONY recipes in Makefiles, when you could just have a directory full of shell scripts. If you find yourself using .PHONY recipes, then you already have a reason to use just. Well, I think it's the same question, rather than a better question. And the answer is yes, if all you need from make, now and in the future, is a set of .PHONY targets, then by all means just use shell scripts. make is used because often you need slightly more than this -- or you may do so tomorrow, and don't want to change the syntax you use to accomplish tasks.
- BeetleB 2y ago
  > There's already an easy way to solve this: $PATH. I have 10 projects. Each with their own set of shell scripts. You want me (and all other developers) to pollute the $PATH with 10 directories? And then you have a namespace problem. I usually have a "test" recipe in my justfiles. The analog would be a test.sh file. But with your solution, it will have to be projA-test.sh and projB-test.sh. And if I dump them all into the $PATH, how do I quickly see the scripts relevant to a particular project?

brushfoot 2y ago

Agreed, particularly if you pipe to fzf. (For those who haven't used it, fzf is a fuzzy-searchable menu for the command line. You pipe lines of input to it, and it shows them in a menu. You start typing and it fuzzy searches the menu and selects the best match. Then you press Enter to pipe that out, or Tab for multi-select. It's fantastic.) I have convenience functions in my profile script that pipe different things to fzf...scripts, paths in the current directory to copy to the clipboard, etc. It's indispensable. Bonus: progressive enhancement. If someone doesn't have fzf/those convenience functions, it's just a directory with shell scripts, so they don't have to do anything special to use them.

slightwinder 2y ago

It's a different approach, none is better or worse, people simply have preferences. And all other features aside, it seems to be able to call commands from any subdirectory in a project, which is actually nice compared with a normal shell. I mean, you can replicate this with some lines of shellscripting, but not everyone seems to maintain an elaborated $BIN of personal tools.

gregwebs 2y ago

I do both. A script directory helps provide the underlying extensible tools. Just is a convenient ui for the most frequent dev use cases of a project.