1. 4
  1. 2

    Good stuff! I have come to many of the same conclusions and even many of the same implementations—especially Make as the primary developer interface to a project.

    My variations include:

    • avoidance of external virtual environment and dependency management (poetry, pipenv, etc.) because they do not yet provide enough value for their costs (given my particular value weightings)
    • slightly more standard Make target names (e.g., “dist” instead of “build” (and I use “build” as “do whatever is needed to make this a working dev environment”); the ones in this video are very close and I don’t see a reason for them to change; for details see https://www.gnu.org/software/make/manual/html_node/Standard-Targets.html#Standard-Targets

    Here’s a representative example of the style of Makefile I use: https://github.com/flowoilwell/otable/blob/master/Makefile

    Here’s a slightly more complex example; I especially like how coverage is done in this project: https://github.com/benji-york/manuel/blob/master/Makefile

    1. 3

      Neat. Thank you for the compliment and for sharing. I really like the conditional definition of release in the second example. I’m going to meditate on that a bit and see if there’s a way I can safeguard some tasks similarly. Our releases are done on CI; no one can should push from local builds but I think I’ve got some other tasks worth guarding.

      1. 2

        I’m glad you saw something interesting there.

        For a slightly wilder Make experiment, check out this alternative way of specifying PHONY targets: https://twitter.com/benji_york/status/1550138533494628357