5 ms·

A stupid simple make wrapper that makes my life easier

69 points by wurosh 5y ago

wurosh 5y ago
The README says it all. I kept writing Makefiles that ran build targets in Docker in a shoddy way. I just wrote a slightly less shoddy POSIX sh wrapper that does it for me. It's nothing fancy, but it makes my life easier and it's super simple to use.
rurban 5y ago
on macOs I had to skip the in_docker_group check. And the escape sequences did not work
- wurosh 5y ago
  Interesting. I don't have access to a Mac, so a bit of extra information would be helpful. Could you open an issue on the repo? I know docker desktop uses a virtialized linux kernel on Mac, but I assumed access would still be controlled through user groups. Is there an alternative check I can do? I'd be more than happy to add MacOS specific logic. I'll look into how escape sequences work on Mac as well.
- wurosh 5y ago
  I ended up disabling the check - it's more trouble than it's worth.
commachika 5y ago
Fauci is a fucking genocidal fascist. Fauci must be executed on live tv!
zfrag 5y ago
KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI!
bluehatbrit 5y ago
Looks interesting! Not to put a dampener on the project but the name clashes with Cake (C# Make) project which could be confusing - https://cakebuild.net/ https://cakebuild.net/ None the less this looks like a useful tool.
- tgv 5y ago
  I don't mind name clashes: there so many projects, and only a handful of words. Macker could be a good name, though.
- wurosh 5y ago
  Oh, I didn't know, I spend all of my time working with Linux so I'm a bit out of touch with that space. I'll see if I can come up with a nice short name that doesn't clash
BiteCode_dev 5y ago
A bit of a plug, but if you are using python in your project already, give a try to pydoit (pydoit.org/). It completely replaced make, task runners or build systems for me. Pydoit is the sweet spot for most of my use cases: - it scales up (graph of deps, file watcher, etc) but above all, it scales DOWN (simple stuff are dead simple) - it promotes a declarative task definition - it embraces the shell yet let you use python if you need to - it gets out of your way and doesn't try to rule your project. It just runs what you want and disapear. - the doc is nice The biggest drawback is that you need to pip install it, which means non python devs will avoid it. I wish it was provided as an stand alone executable
- hprotagonist 5y ago
  a meta-plug is in order for pipx, then: https://pipxproject.github.io/pipx/ https://pipxproject.github.io/pipx/ which wholly abstracts "pip install this thing that has an entry_point without hating your life."
  - mitchbob 5y ago
    Thanks! New URL: https://pypa.github.io/pipx/ https://pypa.github.io/pipx/
- agumonkey 5y ago
  https://pydoit.org/ https://pydoit.org/
- cryptonector 5y ago
  Having to work with multi-language codebases cures one real fast of any interest in single-language build systems. Still, make kinda sucks. I've yet to meet a build system that ticks these boxes: multi-language, simple, fast.
  - BiteCode_dev 5y ago
    pydoit is not single language in the sense it limits your to tasks for your language. It's completely agnostic in that sense, and I use it for non python projects as well. Even the fact it's using python to declare your tasks is not a problem: it's basically a function signature and a mapping, nothing you can't master in 5 minutes, and certainly simpler than make files DSL. Also easier to get right and debug. The problem is the fact you need python to install it and run it, which non python dev will rightfully not care to do.
deleted 5y ago
[deleted]
florianist 5y ago
Before releasing a script, it's always a good idea to fix the errors reported by Shellcheck. There are several here. Also the script has a /bin/sh shebang and README says it's POSIX but it has bashims (for example "echo -e" will fail in default /bin/sh in Debian).
- Hello71 5y ago
  there are more issues after fixing all of those: grep -w is not POSIX, the exit status of type is not clearly defined by POSIX, realpath is not POSIX, basename is POSIX but can be replaced with ${path##*/} for most well-formed paths (gives different results for /, but this script doesn't work properly for / anyways?), inodes are not unique across devices, --directory=dir has ugly handling but seems to work but --directory dir doesn't (i think it silently sets the directory to --directory and then passes dir as a separate argument?)
  - wurosh 5y ago
    I fixed everything you mentioned. I kept basepath because it handles more edge cases. I improved the option parsing to handle --directory dir, although that is neither here nor there (it's GNU.. -ish). The handling is ugly for the sake of POSIX compatibility - if you can think of a more elegant way to write it let me know, I'd be glad to incorporate it. The exit status of type is clearly defined by POSIX (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/type.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/t...). Either way, thank you for the exhaustive list of problems, it really helped - please don't hesitate to open issues with any further observations.
    - Hello71 5y ago
      more specifically the problem with type is it's not clear whether "An error occurred" includes the case where the command is not found. one could reasonably argue that printing "command not found" is a successful run. additionally, it's only present in the XSI extension. for these reasons, command -v is usually preferred for better POSIX compatibility.
- 5y ago
rcarmo 5y ago
I like the idea, but since I’m so used to using make for everything, I would probably just bake in a Makefile with the shell bits I found most useful for each container instead.
0xbadcafebee 5y ago
Mm. I've gone this way before, and eventually it breaks down. make just isn't that composeable. I have even made fancy Makefiles that allow me to pass command-line arguments to targets. At the end of the day, what you really want is a wrapper program that gives you specific composeable functionality, and Make isn't that.
- wurosh 5y ago
  I did want that functionality in the past, but it's not exactly what I'm trying to achieve (but if you find a tool that does, please post it here). I don't want to run arbitrary commands in a container. I want to build software in a container so I don't have to think about its dependencies (as much). I should probably clarify that in the README
Arch-TK 5y ago
"The Makefile is the single source of truth for dev commands" This feels like when you set up a club for a hobby you enjoy, let's say it's beer pong, and you go on holiday for a month, you come back to find that your beer pong club is now full of people just chugging lots of beer and completely ignoring the game. Please, make is a sophisticated tool with lots of good features. It is NOT a repository for "dev commands" whatever the hell that means. Make is a tool which takes targets, dependencies and recipes and turns them into a DAG which it then executes based on a set of criteria. If you want a glorified shell script which runs commands, why not just do a bash script with a switch in it? It's certainly going to behave a lot more like you expect. Why call it cake when it has almost nothing to do with make?
- ataylor32 5y ago
  > why not just do a bash script with a switch in it? Here is another alternative: https://github.com/TekWizely/run https://github.com/TekWizely/run
  - TekWizely 5y ago
    Hey thanks for the bump ! I sometimes chime in on posts where OP makes a tool in the same domain as Run. When I hit this article yesterday, the bash script convo hadn't started yet and I saw the OPs creation as not being in the same realm as Run, so didn't chime in. But now that its been mentioned :) Anyway I got a few extra subs from your call out, so thanks again for that! (actually I just spent the last 30 mins reviewing 24 hours of HN posts to see where the call out might have come from, and finally found it :) -- Surprisingly google hasn't indexed this post yet so didn't show up in my saved search )
- aequitas 5y ago
  > It is NOT a repository for "dev commands" whatever the hell that means. What it means is that it doesn't matter if I run `make test`, my coworker runs `make test` or the CI system runs `make test`, we all end up with the same result. Namely that the test suite will be run, after all stuff is done that is needed to setup the dev environment. Basically you codify all actions you as a developer would need, to setup, verify or use a project and all the dependencies between them. This makes your projects portable and when you have multiple projects (in different languages), getting it setup and running the test suite is the same for each one of them. Why not use a bash script? That's how I started off but once a coworker introduced me to Make I never looked back. Bash scales really badly in terms of readability and maintainability.
TekWizely 5y ago
I see this post has finally devolved into a discussion around using make as a task runner (it hadn't yet when I first read the article yesterday) With that in mind, I toss my tool into the ring: Run: Easily manage and invoke small scripts and wrappers - https://github.com/TekWizely/run https://github.com/TekWizely/run

69 points by wurosh 5y ago

The README says it all. I kept writing Makefiles that ran build targets in Docker in a shoddy way. I just wrote a slightly less shoddy POSIX sh wrapper that does it for me. It's nothing fancy, but it makes my life easier and it's super simple to use.

rurban 5y ago

on macOs I had to skip the in_docker_group check. And the escape sequences did not work

wurosh 5y ago
Interesting. I don't have access to a Mac, so a bit of extra information would be helpful. Could you open an issue on the repo? I know docker desktop uses a virtialized linux kernel on Mac, but I assumed access would still be controlled through user groups. Is there an alternative check I can do? I'd be more than happy to add MacOS specific logic. I'll look into how escape sequences work on Mac as well.
wurosh 5y ago
I ended up disabling the check - it's more trouble than it's worth.

commachika 5y ago

Fauci is a fucking genocidal fascist. Fauci must be executed on live tv!

zfrag 5y ago

KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI! KILL FAUCI!

bluehatbrit 5y ago

Looks interesting! Not to put a dampener on the project but the name clashes with Cake (C# Make) project which could be confusing - https://cakebuild.net/ https://cakebuild.net/ None the less this looks like a useful tool.

tgv 5y ago
I don't mind name clashes: there so many projects, and only a handful of words. Macker could be a good name, though.
wurosh 5y ago
Oh, I didn't know, I spend all of my time working with Linux so I'm a bit out of touch with that space. I'll see if I can come up with a nice short name that doesn't clash

BiteCode_dev 5y ago

A bit of a plug, but if you are using python in your project already, give a try to pydoit (pydoit.org/). It completely replaced make, task runners or build systems for me. Pydoit is the sweet spot for most of my use cases: - it scales up (graph of deps, file watcher, etc) but above all, it scales DOWN (simple stuff are dead simple) - it promotes a declarative task definition - it embraces the shell yet let you use python if you need to - it gets out of your way and doesn't try to rule your project. It just runs what you want and disapear. - the doc is nice The biggest drawback is that you need to pip install it, which means non python devs will avoid it. I wish it was provided as an stand alone executable

hprotagonist 5y ago
a meta-plug is in order for pipx, then: https://pipxproject.github.io/pipx/ https://pipxproject.github.io/pipx/ which wholly abstracts "pip install this thing that has an entry_point without hating your life."
- mitchbob 5y ago
  Thanks! New URL: https://pypa.github.io/pipx/ https://pypa.github.io/pipx/
agumonkey 5y ago
https://pydoit.org/ https://pydoit.org/
cryptonector 5y ago
Having to work with multi-language codebases cures one real fast of any interest in single-language build systems. Still, make kinda sucks. I've yet to meet a build system that ticks these boxes: multi-language, simple, fast.
- BiteCode_dev 5y ago
  pydoit is not single language in the sense it limits your to tasks for your language. It's completely agnostic in that sense, and I use it for non python projects as well. Even the fact it's using python to declare your tasks is not a problem: it's basically a function signature and a mapping, nothing you can't master in 5 minutes, and certainly simpler than make files DSL. Also easier to get right and debug. The problem is the fact you need python to install it and run it, which non python dev will rightfully not care to do.

deleted 5y ago

[deleted]

florianist 5y ago

Before releasing a script, it's always a good idea to fix the errors reported by Shellcheck. There are several here. Also the script has a /bin/sh shebang and README says it's POSIX but it has bashims (for example "echo -e" will fail in default /bin/sh in Debian).

Hello71 5y ago
there are more issues after fixing all of those: grep -w is not POSIX, the exit status of type is not clearly defined by POSIX, realpath is not POSIX, basename is POSIX but can be replaced with ${path##*/} for most well-formed paths (gives different results for /, but this script doesn't work properly for / anyways?), inodes are not unique across devices, --directory=dir has ugly handling but seems to work but --directory dir doesn't (i think it silently sets the directory to --directory and then passes dir as a separate argument?)
- wurosh 5y ago
  I fixed everything you mentioned. I kept basepath because it handles more edge cases. I improved the option parsing to handle --directory dir, although that is neither here nor there (it's GNU.. -ish). The handling is ugly for the sake of POSIX compatibility - if you can think of a more elegant way to write it let me know, I'd be glad to incorporate it. The exit status of type is clearly defined by POSIX (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/type.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/t...). Either way, thank you for the exhaustive list of problems, it really helped - please don't hesitate to open issues with any further observations.
  - Hello71 5y ago
    more specifically the problem with type is it's not clear whether "An error occurred" includes the case where the command is not found. one could reasonably argue that printing "command not found" is a successful run. additionally, it's only present in the XSI extension. for these reasons, command -v is usually preferred for better POSIX compatibility.
5y ago

rcarmo 5y ago

I like the idea, but since I’m so used to using make for everything, I would probably just bake in a Makefile with the shell bits I found most useful for each container instead.

0xbadcafebee 5y ago

Mm. I've gone this way before, and eventually it breaks down. make just isn't that composeable. I have even made fancy Makefiles that allow me to pass command-line arguments to targets. At the end of the day, what you really want is a wrapper program that gives you specific composeable functionality, and Make isn't that.

wurosh 5y ago
I did want that functionality in the past, but it's not exactly what I'm trying to achieve (but if you find a tool that does, please post it here). I don't want to run arbitrary commands in a container. I want to build software in a container so I don't have to think about its dependencies (as much). I should probably clarify that in the README

Arch-TK 5y ago

"The Makefile is the single source of truth for dev commands" This feels like when you set up a club for a hobby you enjoy, let's say it's beer pong, and you go on holiday for a month, you come back to find that your beer pong club is now full of people just chugging lots of beer and completely ignoring the game. Please, make is a sophisticated tool with lots of good features. It is NOT a repository for "dev commands" whatever the hell that means. Make is a tool which takes targets, dependencies and recipes and turns them into a DAG which it then executes based on a set of criteria. If you want a glorified shell script which runs commands, why not just do a bash script with a switch in it? It's certainly going to behave a lot more like you expect. Why call it cake when it has almost nothing to do with make?

ataylor32 5y ago
> why not just do a bash script with a switch in it? Here is another alternative: https://github.com/TekWizely/run https://github.com/TekWizely/run
- TekWizely 5y ago
  Hey thanks for the bump ! I sometimes chime in on posts where OP makes a tool in the same domain as Run. When I hit this article yesterday, the bash script convo hadn't started yet and I saw the OPs creation as not being in the same realm as Run, so didn't chime in. But now that its been mentioned :) Anyway I got a few extra subs from your call out, so thanks again for that! (actually I just spent the last 30 mins reviewing 24 hours of HN posts to see where the call out might have come from, and finally found it :) -- Surprisingly google hasn't indexed this post yet so didn't show up in my saved search )
aequitas 5y ago
> It is NOT a repository for "dev commands" whatever the hell that means. What it means is that it doesn't matter if I run `make test`, my coworker runs `make test` or the CI system runs `make test`, we all end up with the same result. Namely that the test suite will be run, after all stuff is done that is needed to setup the dev environment. Basically you codify all actions you as a developer would need, to setup, verify or use a project and all the dependencies between them. This makes your projects portable and when you have multiple projects (in different languages), getting it setup and running the test suite is the same for each one of them. Why not use a bash script? That's how I started off but once a coworker introduced me to Make I never looked back. Bash scales really badly in terms of readability and maintainability.

TekWizely 5y ago

I see this post has finally devolved into a discussion around using make as a task runner (it hadn't yet when I first read the article yesterday) With that in mind, I toss my tool into the ring: Run: Easily manage and invoke small scripts and wrappers - https://github.com/TekWizely/run https://github.com/TekWizely/run