1. 8
  1. 3

    Scripts to Rule Them All is such an effective and underestimated solution, I get the impression that some people consider the technique ‘dirty’, or too simplistic (as if professional developers wouldn’t do it that way). It’s really powerful though.

    1. 2

      I find it fascinating that this arrived at a similar set of conclusions to how Heroku’s buildpacks work. Namely, both use well-known scripts at well-known paths relative to the project root to capture the generic set of steps required to work with that project.

      I also see these sorts of standards as an entrypoint for a new developer to dive into how a project is supposed to work. It serves as a kind of introductory documentation-as-code for how general tasks are specifically implemented for the particular project, since it details the specific commands the project relies on for the given task (e.g., using make vs. cmake vs. rake vs…). I find it more developer-friendly than the common README pattern, since it’s actually functional and provides a simplified interface to the project’s life-cycle, regardless of the complexity of the project.

      1. 1

        Yes great example! I haven’t worked with them, but now that I think about it they are using very much the same pattern.

        https://github.com/ryandotsmith/null-buildpack/tree/master/bin

        I think this would have been better than the .travis.yml and .github/workflow.yml stuff … i.e. you push and make stuff happen through a language, not a weird YAML config. I’ll have to think about it

      2. 2

        A few people asked me about the “Task file” pattern (variously called run.sh, “go” script, etc.)

        I just added this Github blog post to my list of related examples:

        Four More Posts in “Shell: The Good Parts” (It would have been nice to expand this into a nice blog post, maybe someday)

        Here is a real example: https://github.com/github/linguist/tree/master/script

        Notice that some scripts are Ruby; some are shell. That is how you’re supposed to use shell! It’s a polyglot system.

        “Task file” is perhaps slightly inaccurate since it’s a script directory in this case, not a file. But it serves the same purpose.

        Related to this comment: https://lobste.rs/s/iofste/please_stop_writing_shell_scripts#c_asvpef

        1. 4

          Notice that some scripts are Ruby; some are shell. That is how you’re supposed to use shell! It’s a polyglot system.

          I just want to reinforce your statement via a quotation from Eric Raymond’s “The Art of UNIX Programming”, section “Applying the Unix Philosophy”:

          • Mixing languages is better than writing everything in one, if and only if using only that one is likely to overcomplicate the program.
        2. 1

          I’ve used this pattern successfully at several companies.

          I will say, from a maintenance perspective, that you really want to separate out the OS-specific bits instead of accumulating flags. With Linux, Mac, and now Mac M1 users, you’ll definitely accumulate cruft and this invariably leads to sadness. Just separate out that stuff and copy and paste, and don’t try to be clever about it.