3 ms·

> 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

by 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.
      - pdimitar 2y ago
        Apologies for assuming you downvoted me then. :) And I have not touched your comment btw. I rarely downvote these days and I have to be really pissed to do so. I was not pissed earlier, more like a little frustrated as you seemed to ask without reading, as if demanding a complete answer without willing to piece together the info given in several other comments. So... you were talking about global scripts. I was not. I was talking about per-project directory with scripts because very often projects have their little quirks that make all their scripts frustratingly 99% identical but never 100%. I danced this tango dozens of times -- not exaggerating, I am a contractor (though I hope to finally stop, currently looking for a proper long-term job with good culture fit) and worked on many projects -- and ultimately got extremely frustrated. At one point I did attempt to make those universal scripts you speak of. The even more maddening thing is that they worked for part of the projects... and didn't work for others. It was a rough 60/40 split. So you end up maintaining even more of them. So I gave up. Very soon before that I found `just` and very quickly recognized the benefits: project-local commands / scripts, centralized location (just one file), ability to delegate to parent Justfile (i.e. you can have a dedicated folder for Golang projects and that one can contain a Justfile with e.g. `just lint` task that calls `go vet` and `staticcheck` etc., without having to copy-paste that into every Golang project Justfile file, though I actually prefer that nowadays -- better to have completely self-contained tooling after all but still, for super dev-specific stuff that does not belong in version control the parent Justfile workflow is quite a good fit), and a very easy syntax that still allows for doing stuff that will make you pull your hair out if you attempt them with pure sh or bash and if you haven't memorized their specifics over the course of a lifetime (which is something I attempted but gave up on because it was more or less memorization of exceptions of the exceptions). Now, to address this: > I also haven't seen in your previous response how Just is better than a subdir with shell scripts named according to a convention. I am not impressed by conventions that are not enforced with a spiked club. Which means: we the people forget stuff easily. I suffered from that too. Conventions don't mean much when you misspell the script filename or put `-f` instead of `-e` in the `set` call at the top of the script. :) I prefer loud failures and not silent mess-ups. My position is informed by a lot of negative past experiences. Does not mean that my priorities are universal or unconditionally better. Not at all. It means that everything I got through in my career made me appreciate `just` and it was a near-perfect fit for my needs. > 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. Sure, it encouraged me to finally settle on a naming convention but I've done this before as well. I still prefer the singular file approach + ability to delegate to parent files. The less files in total the better. I have found this rule to make me more productive. If you have gotten this far: nowhere did I claim objective improvements. I had discussions in the past (might have been in other `just` threads even!) with curmudgeons who loudly proclaimed "skill issue!" on my non-preference towards make's bash-isms and weird rules. So for them `make` + other scripts (even Perl / Python ones) are working just fine and the rest are "kids running after shiny toys". I don't mind them thinking that. I have my motivation and, as said above, it's well-motivated given my past and my way of work and mental preferences. Hope that helps.
- lijok 2y ago
  [flagged]
  - pdimitar 2y ago
    My comments are frustrated because I believe a response was already given to the question you asked. I'll be grateful if you at least don't misrepresent, even if it's difficult to find a common language. If you don't believe that I responded adequately then just ask a more detailed question. But sure, here's one more reason for you, as said in a sibling subthread: I can have all my project's commands in one file. Also it pays off to know what `just` does. As several other people were told (not only by me) in the bigger thread, it's an aggregating task runner, more or less. Not a dependency manager.
  - burnished 2y ago
    Honestly you're coming off a bit shit here, I don't read the other person's responses as defensive or insecure at all, so I suspect you're saying that to be rude.
kstrauser 2y ago
Tab completion. `just -l<tab>` shows all the commands and their descriptions. Aside from that, it has lots of built-in ergonomics like consistent argument parsing, functions to say what OS you’re on, an easy way to hide helper functions, the ability to execute a justfile in a great-grandparent directory, etc. You can totally do any of those things with shell scripts. I prefer letting someone else invent all the bells and whistles there so I don’t have to.
- brabel 2y ago
  I am a bit confused. If you have your scripts in `scripts/`, doing `scripts/TAB` will also auto-complete! The other things seem like really minor benefits to me, not trying to say you should also feel the same, just giving my opinion.
  - pdimitar 2y ago
    In my case I prefer all these utility scripts to be in one file because 90% of them are 1-2 lines anyway. Zero point dedicating a directory with several 5-line files.
  - kstrauser 2y ago
    Scripts/tab won’t show you the documentation of each script explaining what it’s for. My genuine advice is to download it and play with it for an hour. If you don’t like it, you’ve learned a little about a tool you’re bound to come across sometime. If you do like it, now you’ve added another tool to your palette. Either way you learn something useful.
- raffraffraff 2y ago
  I use "make", so I get most of this. But the one thing I would like is a sibling / parent / grandparent directory with ease, so I might switch.
  - kstrauser 2y ago
    I’ve used make for many things over the years. I’m competent with it. Make is such a breath of fresh air for the uses that don’t involve actually incrementally building software. It’s sooo less verbose. It’s hard to describe the feel of a thing, but imagine learning to program with Java and then finding Python. If you’re building a giant app developed by thousands of people, maybe Java’s complexity starts to show a benefit. If you just want to quickly script something up, Python gets the job done with a tenth the boilerplate. There’s room for both. Neither replaces the other. But it turns out many of my projects need tools closer to Python/Just than Java/Make.

by lijok 2y ago

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.
    - pdimitar 2y ago
      Apologies for assuming you downvoted me then. :) And I have not touched your comment btw. I rarely downvote these days and I have to be really pissed to do so. I was not pissed earlier, more like a little frustrated as you seemed to ask without reading, as if demanding a complete answer without willing to piece together the info given in several other comments. So... you were talking about global scripts. I was not. I was talking about per-project directory with scripts because very often projects have their little quirks that make all their scripts frustratingly 99% identical but never 100%. I danced this tango dozens of times -- not exaggerating, I am a contractor (though I hope to finally stop, currently looking for a proper long-term job with good culture fit) and worked on many projects -- and ultimately got extremely frustrated. At one point I did attempt to make those universal scripts you speak of. The even more maddening thing is that they worked for part of the projects... and didn't work for others. It was a rough 60/40 split. So you end up maintaining even more of them. So I gave up. Very soon before that I found `just` and very quickly recognized the benefits: project-local commands / scripts, centralized location (just one file), ability to delegate to parent Justfile (i.e. you can have a dedicated folder for Golang projects and that one can contain a Justfile with e.g. `just lint` task that calls `go vet` and `staticcheck` etc., without having to copy-paste that into every Golang project Justfile file, though I actually prefer that nowadays -- better to have completely self-contained tooling after all but still, for super dev-specific stuff that does not belong in version control the parent Justfile workflow is quite a good fit), and a very easy syntax that still allows for doing stuff that will make you pull your hair out if you attempt them with pure sh or bash and if you haven't memorized their specifics over the course of a lifetime (which is something I attempted but gave up on because it was more or less memorization of exceptions of the exceptions). Now, to address this: > I also haven't seen in your previous response how Just is better than a subdir with shell scripts named according to a convention. I am not impressed by conventions that are not enforced with a spiked club. Which means: we the people forget stuff easily. I suffered from that too. Conventions don't mean much when you misspell the script filename or put `-f` instead of `-e` in the `set` call at the top of the script. :) I prefer loud failures and not silent mess-ups. My position is informed by a lot of negative past experiences. Does not mean that my priorities are universal or unconditionally better. Not at all. It means that everything I got through in my career made me appreciate `just` and it was a near-perfect fit for my needs. > 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. Sure, it encouraged me to finally settle on a naming convention but I've done this before as well. I still prefer the singular file approach + ability to delegate to parent files. The less files in total the better. I have found this rule to make me more productive. If you have gotten this far: nowhere did I claim objective improvements. I had discussions in the past (might have been in other `just` threads even!) with curmudgeons who loudly proclaimed "skill issue!" on my non-preference towards make's bash-isms and weird rules. So for them `make` + other scripts (even Perl / Python ones) are working just fine and the rest are "kids running after shiny toys". I don't mind them thinking that. I have my motivation and, as said above, it's well-motivated given my past and my way of work and mental preferences. Hope that helps.
lijok 2y ago
[flagged]
- pdimitar 2y ago
  My comments are frustrated because I believe a response was already given to the question you asked. I'll be grateful if you at least don't misrepresent, even if it's difficult to find a common language. If you don't believe that I responded adequately then just ask a more detailed question. But sure, here's one more reason for you, as said in a sibling subthread: I can have all my project's commands in one file. Also it pays off to know what `just` does. As several other people were told (not only by me) in the bigger thread, it's an aggregating task runner, more or less. Not a dependency manager.
- burnished 2y ago
  Honestly you're coming off a bit shit here, I don't read the other person's responses as defensive or insecure at all, so I suspect you're saying that to be rude.

kstrauser 2y ago

Tab completion. `just -l<tab>` shows all the commands and their descriptions. Aside from that, it has lots of built-in ergonomics like consistent argument parsing, functions to say what OS you’re on, an easy way to hide helper functions, the ability to execute a justfile in a great-grandparent directory, etc. You can totally do any of those things with shell scripts. I prefer letting someone else invent all the bells and whistles there so I don’t have to.

brabel 2y ago
I am a bit confused. If you have your scripts in `scripts/`, doing `scripts/TAB` will also auto-complete! The other things seem like really minor benefits to me, not trying to say you should also feel the same, just giving my opinion.
- pdimitar 2y ago
  In my case I prefer all these utility scripts to be in one file because 90% of them are 1-2 lines anyway. Zero point dedicating a directory with several 5-line files.
- kstrauser 2y ago
  Scripts/tab won’t show you the documentation of each script explaining what it’s for. My genuine advice is to download it and play with it for an hour. If you don’t like it, you’ve learned a little about a tool you’re bound to come across sometime. If you do like it, now you’ve added another tool to your palette. Either way you learn something useful.
raffraffraff 2y ago
I use "make", so I get most of this. But the one thing I would like is a sibling / parent / grandparent directory with ease, so I might switch.
- kstrauser 2y ago
  I’ve used make for many things over the years. I’m competent with it. Make is such a breath of fresh air for the uses that don’t involve actually incrementally building software. It’s sooo less verbose. It’s hard to describe the feel of a thing, but imagine learning to program with Java and then finding Python. If you’re building a giant app developed by thousands of people, maybe Java’s complexity starts to show a benefit. If you just want to quickly script something up, Python gets the job done with a tenth the boilerplate. There’s room for both. Neither replaces the other. But it turns out many of my projects need tools closer to Python/Just than Java/Make.