By the way, many Foreman projects contain Makefiles for i18n purposes and IIRC it was me who added it. Git blame shows that Ohad initially created a rake task for that. I do not remember why I did that, but my guess would be - I did not like rake at the time. I am not sure I like it today tho.
Help targets can be dynamically generated, there are multiple ways how to do this. This should not be a problem. I am little bit more concerned about the targets themselves, but perhaps in the LLM world that should not be a problem.
That is why I think a hybrid approach of defining just minimum amount of targets + fallback to rake could work:
My own two cents:
It really depends on the path we want to take with our architecture and developer experience:
There is an option to separate the UI work out of the rails application (to either separate container(s) or just to different tooling). In this case having a standard-ish makefile makes sense.
If we continue with the Rails as our main driver for everything, I like Ewoud’s opinion about relying more on the tools that are supplied by the main framework that we use. In our case, it is Ruby on Rails. And this framework already comes with a lot of tools that are developer oriented, like the generator, rake and in Rails 7 also the UI framework support.
I do think that leaning more into the standard Rails tooling should be our main goal in this scenario.
Having said that, the move to a containerized development can have some impact on this decision, since in this case, the whole ruby stack will be hidden in the container. And in such cases I think we should explore the concept of devcontainers.
@ekohl I am curious on your thoughts with Make being used in foremanctl? I am asking since using Make to interact with containers isn’t uncommon compared to using Make to interact with ruby is more uncommon.
