5 ms·

There are so many gotcha with makefiles yet we still use them regularly. I'm considering moving on to something like Taskfile [1], though I haven't tried it ye

There are so many gotcha with makefiles yet we still use them regularly. I'm considering moving on to something like Taskfile [1], though I haven't tried it yet. [1]: https://taskfile.org/ https://taskfile.org/

igor47 8y ago
I've been using invoke [1] which has allowed me to give my projects nice UIs while remaining in the primary language. If I were working on Ruby I would stick with Rake, even though I think invoke is better. [1] http://www.pyinvoke.org/ http://www.pyinvoke.org/
- learned 8y ago
  I'll second invoke. I use it for all of my python projects now and I love working with it. It makes it very clean to manage more complex tasks that have a lot of conditionals involved.
- tedmiston 8y ago
  I really like Invoke / Fabric for Python projects, though it feels weird to use in non-Python projects when it comes to dependencies. [Now I have to explain to non-Python people things like virtual envs, pipenv vs pip vs pipsi, pyenv, etc.] Just curious if you install Invoke individually for each project or keep one global install? I suppose I could always git exclude the tasks.py Invoke files.
  - learned 8y ago
    I usually keep Invoke globally installed that way I can use it for setting up and interacting with pipenvs externally. Most of my calls beside the initial setup make use of 'pipenv run <command>' that way I never actually have to navigate inside of the virtualenv for most cases.
SamWhited 8y ago
I decided a long time ago that it's not worth having to install and learn a different tool for every ecosystem just to avoid make's quirks. Yes, make isn't perfect (it can even be quite annoying at times), but neither is everything else so it's worth it to me (from a personal and business perspective) to just make my developers use one thing for all projects, especially since it's already installed (or easily installable if not, there are packages for everything which may not be true of all the less popular alternatives) on most of their systems. Not that I couldn't ever see making an exception to that, I'm sure there are some things out there that don't work with the make model and really do need their own build system, but in general make is "good enough" and it's not worth using anything else.
- tedmiston 8y ago
  I pretty much went down the same path, though with all of Make's quirks, my generic Makefiles end up being nothing more than an index of commands that instead run bash scripts. But then the problem is shifted into bash's error prone syntax. So then for non-trivial logic, I end up having the bash script call a Python script, especially if dependencies are involved. It would be nice to have something like EditorConfig for project commands, i.e., my Sublime or your VS Code could parse one common Makefile (or similar) and map its commands to Build, Run, Debug, etc in the UI. In some sense, I think a different real solution is to Dockerize everything and then just docker build / docker run. Of course this can get complex for some projects, especially where the local setup is different than the production setup, e.g., Docker Compose vs Kubernetes for instance.

igor47 8y ago

I've been using invoke [1] which has allowed me to give my projects nice UIs while remaining in the primary language. If I were working on Ruby I would stick with Rake, even though I think invoke is better. [1] http://www.pyinvoke.org/ http://www.pyinvoke.org/

learned 8y ago
I'll second invoke. I use it for all of my python projects now and I love working with it. It makes it very clean to manage more complex tasks that have a lot of conditionals involved.
tedmiston 8y ago
I really like Invoke / Fabric for Python projects, though it feels weird to use in non-Python projects when it comes to dependencies. [Now I have to explain to non-Python people things like virtual envs, pipenv vs pip vs pipsi, pyenv, etc.] Just curious if you install Invoke individually for each project or keep one global install? I suppose I could always git exclude the tasks.py Invoke files.
- learned 8y ago
  I usually keep Invoke globally installed that way I can use it for setting up and interacting with pipenvs externally. Most of my calls beside the initial setup make use of 'pipenv run <command>' that way I never actually have to navigate inside of the virtualenv for most cases.

SamWhited 8y ago

I decided a long time ago that it's not worth having to install and learn a different tool for every ecosystem just to avoid make's quirks. Yes, make isn't perfect (it can even be quite annoying at times), but neither is everything else so it's worth it to me (from a personal and business perspective) to just make my developers use one thing for all projects, especially since it's already installed (or easily installable if not, there are packages for everything which may not be true of all the less popular alternatives) on most of their systems. Not that I couldn't ever see making an exception to that, I'm sure there are some things out there that don't work with the make model and really do need their own build system, but in general make is "good enough" and it's not worth using anything else.

tedmiston 8y ago
I pretty much went down the same path, though with all of Make's quirks, my generic Makefiles end up being nothing more than an index of commands that instead run bash scripts. But then the problem is shifted into bash's error prone syntax. So then for non-trivial logic, I end up having the bash script call a Python script, especially if dependencies are involved. It would be nice to have something like EditorConfig for project commands, i.e., my Sublime or your VS Code could parse one common Makefile (or similar) and map its commands to Build, Run, Debug, etc in the UI. In some sense, I think a different real solution is to Dockerize everything and then just docker build / docker run. Of course this can get complex for some projects, especially where the local setup is different than the production setup, e.g., Docker Compose vs Kubernetes for instance.