4 ms·

I prefer to take it one abstraction further and setup a makefile where the default `make` brings up the app. This makes it so you can rework the runtime as you

I prefer to take it one abstraction further and setup a makefile where the default `make` brings up the app. This makes it so you can rework the runtime as you see fit and nothing changes. It also doesn't require you to jump into docker immediately, and gives a good extension point for various 'helper script' workflows that you will always have.

gravypod 6y ago
Makefiles are nice in theory but don't scale well to team members who don't know how to use make. If your team is full of experienced C/C++ devs then this will probably work great for you. If you are working with a bunch of android/javascript/etc developers who've never seen make, and who haven't exercised the skillset of reading through 3-decade-old email threads to find answers, you'll find that the only thing you'll do is "make" them upset.
- JamesSwift 6y ago
  Dont these issues also apply to the docker-compose alternative? I'm recommending make as "the one tool" to use for all of your teams apps. No matter what app they work on, everything is setup with `make bootstrap` and everything is run with `make up`. Everything is deployed with `make deploy`. They dont need to understand the _how_, only the _what_.
  - gravypod 6y ago
    No, other tools do not suffer from what makes make complex. Make is "hard" because of a few things: 1. The syntax is very complex 2. It's just a wrapper around shell command execution 3. There's no single standard everyone fully implements If I implemented a makefile then I'd have to make sure it's compatible with MacOS and GNU Make. The syntax for make files and target deps are also very complex "Do I want to use % or $ or @?" Make also implements very few pieces of functionality. It forks out SHELL for most things and because of this you need to have everything your makefile is using installed on your system. If you have a makefile, invariably, someone implements some tool that's super helpful and works.... until it doesn't. It depends on some system configuration or utility that is no longer a dep of something you've manually installed and the makefile breaks. If you use containers for all of your functionality this is no longer an issue because you can vendor base layers of OSs/images and make sure they don't break. You can also test these changes, that could be breaking, without rolling out to other developers. I cannot test if my Makefile will run on a developer's mac if I don't have a mac myself and even then it's a crap shoot (do they have homebrew? is their PATH correct? etc).
    - patrick451 6y ago
      > The syntax for make files and target deps are also very complex "Do I want to use % or $ or @?" How is this any more complex than any programming language? Take javascript. Do I want to use =, ==, or ===? > I cannot test if my Makefile will run on a developer's mac if I don't have a mac myself and even then it's a crap shoot (do they have homebrew? is their PATH correct? etc). Containers suffer from these kinds of problems as well. For example, if your ip tables are not set up just so, you get no network access from inside your container.
- nthj 6y ago
  C. S. Lewis taught me newness is no virtue, and oldness is no vice. I’ll leave the answer as to why I’m quoting a writer on religion in response to an anecdote on developers’ quirks about their environment as an exercise to the reader.
- spanhandler 6y ago
  Yeah but if you use bare tools then it’s hard to change them and the interface may differ project to project. If you let the JS developers pick your universal build tool then they’ll want to change it annually because now the old one they loved is “terrible” and some other thing is great and is definitely the way forward. Plus then you’ll need node on every machine that needs to run the build, and probably you’ll want to lock the version and not use the one in LTS OS releases because those are too old so now all your poor non-JS developers are installing NVM and Node and a pile of other crap. Or you can just make everyone wrap their build tools in make.
  - gravypod 6y ago
    The solution here is to choose a build system that is language agnostic. The most common of these is docker & docker-compose. There's also the Blaze-likes (Pants, Buck, Bazel, Please) that let you hermetically include tools like node inside of the build chain. Make is not a "wrapper" it's a "translucent layer on top of" since it doesn't hide the deps on the underlying tools. When I do `docker build -t ... something` or `bazel build //something` I don't need to care if it's node, C++, Java, etc. I just need to know that it is a thing that I want to build. Make cannot deliver that to you as you need all of your system toolchains installed and you need to make sure your makefile works on every OS/system config.
    - solraph 6y ago
      > Make is not a "wrapper" it's a "translucent layer on top of" since it doesn't hide the deps on the underlying tools. For me, that's kinda the point. If (when!) the underlying layers break, I can open up the Makefile and see exactly what was called, without too much abstraction. It's not there to provide complex build options, it's to provide aliases to the commonly used commands in a platform agnostic way. Most of my make commands are simply aliases for one or more commands, which are often something like `docker run --rm -it project_runner_image some_command` There's some real problems with Makefiles in the form of tabs as the prefix, running everything as a shell, weird platform specific versions, etc - but I've yet to see anything else which is as small, as universally available, with such a low barrier to entry. Most of the other options I've seen so far (and I'll be the first to admit I haven't looked very hard) seemed to either be overly complex for simple dev setups, or bound to a particular language.
- thiht 6y ago
  > Makefiles are nice in theory but don't scale well to team members who don't know how to use make Just learn it then? Running make commands is trivial. Writing basic make targets is trivial too.
  - pc86 6y ago
    Well the entire linked article and this entire thread (and all the others) could be boiled down to "Just learn [kubernetes,docker,whatever] then?" but that's not super helpful.
- ezekiel68 6y ago
  Not to pile on -- and I'm sure there would be exceptions -- but I've worked with some large and dynamic (employee churn) dev teams and it's always been worth it in my cases, so far, to burn a half day with new people to get them comfortable with Makefiles (and how to fix the common errors when editing them). Teams I've been on have used them for python, ruby, node, Java and Rust[1] codebases (across the years). It's definitely language-agnostic enough on its own. Oh! And the same Makefile is used in the CI/CD pipeline, to make the entire process more likely to be repeatable by our automation tools. [1] Yes, our Makefiles sometimes call docker/npm/ant/maven/gradle/cargo under the hood. Its been worth it, in my experience. One syntax on all projects to set up the workspace, refresh dependencies, deploy to dev env, clean, etc.
- inshadows 6y ago
  > If you are working with a bunch of android/javascript/etc developers who've never seen make, and who haven't exercised the skillset of reading through 3-decade-old email threads to find answers, you'll find that the only thing you'll do is "make" them upset. Actually I find most answers either in official documentation or on StackExchange sites. And I much prefer digging in mailing lists over digging in GitHub issues. You access both over web anyway.

gravypod 6y ago

Makefiles are nice in theory but don't scale well to team members who don't know how to use make. If your team is full of experienced C/C++ devs then this will probably work great for you. If you are working with a bunch of android/javascript/etc developers who've never seen make, and who haven't exercised the skillset of reading through 3-decade-old email threads to find answers, you'll find that the only thing you'll do is "make" them upset.

JamesSwift 6y ago
Dont these issues also apply to the docker-compose alternative? I'm recommending make as "the one tool" to use for all of your teams apps. No matter what app they work on, everything is setup with `make bootstrap` and everything is run with `make up`. Everything is deployed with `make deploy`. They dont need to understand the _how_, only the _what_.
- gravypod 6y ago
  No, other tools do not suffer from what makes make complex. Make is "hard" because of a few things: 1. The syntax is very complex 2. It's just a wrapper around shell command execution 3. There's no single standard everyone fully implements If I implemented a makefile then I'd have to make sure it's compatible with MacOS and GNU Make. The syntax for make files and target deps are also very complex "Do I want to use % or $ or @?" Make also implements very few pieces of functionality. It forks out SHELL for most things and because of this you need to have everything your makefile is using installed on your system. If you have a makefile, invariably, someone implements some tool that's super helpful and works.... until it doesn't. It depends on some system configuration or utility that is no longer a dep of something you've manually installed and the makefile breaks. If you use containers for all of your functionality this is no longer an issue because you can vendor base layers of OSs/images and make sure they don't break. You can also test these changes, that could be breaking, without rolling out to other developers. I cannot test if my Makefile will run on a developer's mac if I don't have a mac myself and even then it's a crap shoot (do they have homebrew? is their PATH correct? etc).
  - patrick451 6y ago
    > The syntax for make files and target deps are also very complex "Do I want to use % or $ or @?" How is this any more complex than any programming language? Take javascript. Do I want to use =, ==, or ===? > I cannot test if my Makefile will run on a developer's mac if I don't have a mac myself and even then it's a crap shoot (do they have homebrew? is their PATH correct? etc). Containers suffer from these kinds of problems as well. For example, if your ip tables are not set up just so, you get no network access from inside your container.
nthj 6y ago
C. S. Lewis taught me newness is no virtue, and oldness is no vice. I’ll leave the answer as to why I’m quoting a writer on religion in response to an anecdote on developers’ quirks about their environment as an exercise to the reader.
spanhandler 6y ago
Yeah but if you use bare tools then it’s hard to change them and the interface may differ project to project. If you let the JS developers pick your universal build tool then they’ll want to change it annually because now the old one they loved is “terrible” and some other thing is great and is definitely the way forward. Plus then you’ll need node on every machine that needs to run the build, and probably you’ll want to lock the version and not use the one in LTS OS releases because those are too old so now all your poor non-JS developers are installing NVM and Node and a pile of other crap. Or you can just make everyone wrap their build tools in make.
- gravypod 6y ago
  The solution here is to choose a build system that is language agnostic. The most common of these is docker & docker-compose. There's also the Blaze-likes (Pants, Buck, Bazel, Please) that let you hermetically include tools like node inside of the build chain. Make is not a "wrapper" it's a "translucent layer on top of" since it doesn't hide the deps on the underlying tools. When I do `docker build -t ... something` or `bazel build //something` I don't need to care if it's node, C++, Java, etc. I just need to know that it is a thing that I want to build. Make cannot deliver that to you as you need all of your system toolchains installed and you need to make sure your makefile works on every OS/system config.
  - solraph 6y ago
    > Make is not a "wrapper" it's a "translucent layer on top of" since it doesn't hide the deps on the underlying tools. For me, that's kinda the point. If (when!) the underlying layers break, I can open up the Makefile and see exactly what was called, without too much abstraction. It's not there to provide complex build options, it's to provide aliases to the commonly used commands in a platform agnostic way. Most of my make commands are simply aliases for one or more commands, which are often something like `docker run --rm -it project_runner_image some_command` There's some real problems with Makefiles in the form of tabs as the prefix, running everything as a shell, weird platform specific versions, etc - but I've yet to see anything else which is as small, as universally available, with such a low barrier to entry. Most of the other options I've seen so far (and I'll be the first to admit I haven't looked very hard) seemed to either be overly complex for simple dev setups, or bound to a particular language.
thiht 6y ago
> Makefiles are nice in theory but don't scale well to team members who don't know how to use make Just learn it then? Running make commands is trivial. Writing basic make targets is trivial too.
- pc86 6y ago
  Well the entire linked article and this entire thread (and all the others) could be boiled down to "Just learn [kubernetes,docker,whatever] then?" but that's not super helpful.
ezekiel68 6y ago
Not to pile on -- and I'm sure there would be exceptions -- but I've worked with some large and dynamic (employee churn) dev teams and it's always been worth it in my cases, so far, to burn a half day with new people to get them comfortable with Makefiles (and how to fix the common errors when editing them). Teams I've been on have used them for python, ruby, node, Java and Rust[1] codebases (across the years). It's definitely language-agnostic enough on its own. Oh! And the same Makefile is used in the CI/CD pipeline, to make the entire process more likely to be repeatable by our automation tools. [1] Yes, our Makefiles sometimes call docker/npm/ant/maven/gradle/cargo under the hood. Its been worth it, in my experience. One syntax on all projects to set up the workspace, refresh dependencies, deploy to dev env, clean, etc.
inshadows 6y ago
> If you are working with a bunch of android/javascript/etc developers who've never seen make, and who haven't exercised the skillset of reading through 3-decade-old email threads to find answers, you'll find that the only thing you'll do is "make" them upset. Actually I find most answers either in official documentation or on StackExchange sites. And I much prefer digging in mailing lists over digging in GitHub issues. You access both over web anyway.