cortesi / modd

A flexible developer tool that runs processes and responds to filesystem changes
MIT License
2.79k stars 130 forks source link

Explicitly trigger the execution of specific blocks #67

Open gcsolaroli opened 5 years ago

gcsolaroli commented 5 years ago

Lately I am using modd for more and more projects; anything that does not have a pom.xml file, ends up having a modd.conf one.

One feature that I am missing though, is the ability to run modd clean –when I need to cleanup some mess– or modd install –when I am ready to build the final artefacts for a release.

If modd would allow each block to be explicitly named, and invoked both as parameter of the main command (eg. modd install) and from within another block, it should be possible to achieve both these features.

Running a specific "task" as parameter of the main command should avoid enabling file changes monitoring, and exit as soon as the execution completes; invoking a task from within any other task should not change the exit policy of the main tool, though.

Does this make any sense, or is just me being old enough to try to revive some of the patterns I got used to when using make? :)

cortesi commented 5 years ago

This seems like a good idea, and is also something I want. I'm wondering about the best way to do this. The first step is to extend the modd command to take a selector, so this command would run modd with all the tasks that match the label "foo":

modd foo

We can also allow multiple selectors, so this one will run tasks matching "foo" or "bar":

modd foo bar

The next question is how to indicate which tasks match which selectors. One possibility is to extend the syntax to add block selectors. Th e most natural way to do this is to use the block option syntax - we already have the indir option as prior art:

*.go {
    name: test
    prep: go test ./...
}

*.go {
    name: install
    prep: go install ./cmd/mycmd
}

With this syntax, we can now say modd install or modd test. If no selector is specified, all blocks are run. This suggests another extension: specifying that some blocks should only be run if they are explicitly selected:

*.go {
    name: test
    prep: go test ./...
}

*.go {
    name: install
    prep: go install ./cmd/mycmd
}

{
    skip: true
    name: clean
    prep: rm -rf ./tmp
}

So with the file above:

Any thoughts? There's a possibility for a lighter-weight mechanism that just matches on the text of the commands, but that might be too implicit.

frederikhors commented 5 years ago

I like the simplicity of modd because is not a task manager like https://taskfile.dev or https://github.com/magefile/mage or https://github.com/casey/just or https://github.com/rliebz/tusk or others.

I think modd should remain as it is handling the features it has and which are difficult to find so good in other tools like the ones I listed before:

Any other activity should belong to other task managers. I wrote one for my projects.

Modd is amazing and fast and can be part of other task managers with no problems.

The only problem I have today is the colours (I read in Readme.md but still not solved problem with go-chi project).

My 50 cents.