Adding producer semantics

[sascha-andres]

I have pushed a new feature proposal to discuss: feature/producer

The idea is to have multiple producer that translate the Taskfile to different target formats. So they produce either a series of executed commands or for example a bash script.

Another useful target for a producer would be a dockerfile generator.

@andreynering sorry to directly assign you to this issue, but I wanted to start the discussion about that idea

[zbindenren]

Why would you want that?

[andreynering]

I'm also curious on this use case. I think most people won't need something like this?

But I'm not against it, it's a very interesting idea, actually. I don't know any tool that does something like this...

[sascha-andres]

The idea is to have developers run the setup whereever they want. If they prefer working on their machine use the ExecProducer. If they like to have it "virtualized" then use a DockerProducer. If a colleague calls "Can you run on that machine" use a RemoteProducer which uses ssh. We do have the case for different setups in one project and with that, task would be the abstraction layer to support the different environments.

I do not know another tool being capable of this, I investigated Ansible but that is too much machine centered. This would be lightweight and more a developer perspective than a system administrator's.

[andreynering]

@sascha-andres If you are motivated to work on it, go for it. 👍

I just want the code to keep simple and maintainable, but I don't think this feature will hurt maintainance at all.

[smyrman]

One interesting idea cold be to generate files that a CI will understand, such as Circle CI or Travis. I guess that also means you could generate Makefiles, which I assume is not a goal. As for something that can do something similar, I think CMake might be within that category, in that it can translate CMake files to different formats so that e.g. end-user don't have to use CMake.

I don't know how complex such a producer pattern would be though, so it will be intresting to see how simple you can make it @sascha-andres.

[andreynering]

As a user, I think generating Makefiles would be awesome. The final user could choose to use Task directly or Make.

As a Task developer, though, I think it would be too complicated. Some Task features may not be available in Make and the other way around.

[smyrman]

Indeed @andreynering, but that's probably true for any format you might want to generate this way, including CI yml files, Dockerfiles or even to some extent bash scripts.

But I assume this is kind of what the producer pattern would aim to do @sascha-andres? Or do I misunderstand the intend?

[andreynering]

@smyrman You are right! Maybe we get to the point to generate Makefiles someday, but don't expect it soon...

This branch is just a proposal by now.

---

In the meantime, you can install Task in your CI and than call it. I do it in two projects, currently:

• 1
• 2

Maybe I should add a section in the README about integration with CI...

[sascha-andres]

@andreynering Pushed a new branch for this with an updated and reduced implementation. Like to get some feedback

[andreynering]

@sascha-andres I'm not sure about better way to declare that interface.

I think maybe we should keep execution (what we have today) and generation separated. What do you think?

package generator

type Generator interface {
	Generate(w io.Writer, tasks Tasks) error
}

In Go, in most cases, the smaller the interface, the better.

[andreynering]

Closing this for now. I think it's a bit out of the scope of this project, and also technically difficult to do this.