Struggling to justify Taskfile for Team

[d3dc]

I've spent a couple weeks really trying to love Task. I wanted to see it greatly increase our makefile readability.

However, the people on my team who I impromptu polled had trouble with the ergonomics. The under-specification combined with the surprises of task closures managed to confuse 5/5 devs.

From trying to find examples, the complex Taskfile I found follow from a comment chain of "how do I work around X 'feature'" and contains lots of idiosyncrasy rather than "Thinking in Tasks". test_data doesn't really show much interaction.

Do good Taskfile methodologies exist? How do you advertise defaults and assemble a deployment specific environment?

[d3dc]

I probably need to see the history that went into the v3 priority change. To me, Task v2 seems to only have Taskfile vars out of place - task vars as defaults would've allowed for explicit variable and defaults patterns.

[andreynering]

Hi @d3dc,

I'm really not sure on how to answer this. Perhaps if you were more specific I could extract something useful/actionable from this discussion. Is your complains related to the ENV discussions you opened? Do you have specific proposals to make?

[d3dc]

Hi @andreynering,

I think I was pretty frustrated when I wrote this. I do think it is important to highlight why the tool is tougher to pick up than expected. A lot of our issues around structuring our Makefiles into Taskfiles had to do with adapting contextual dependencies that had previously used "setenv" etc.

I think the thing that would help the most would be another page added to the docs that just describes the "process model". As it is, I have to go all the way to the bottom of the changelog page to find the scope ordering.

The number one mistake we all made was: expecting Tasks to inherit environment and variables. I know when I approached the tool, I thought of tasks as child forks from a "Taskfile shell". It seems like there is more isolation than that, and that may or may not solve some issues by just being explained with rational.

The other part of my original post was voicing that Examples are lacking. Trying again, it still seems go-task/examples is under-loved. I appreciate the idea of "isolated" NPM script replacements - but a large chunk of our deployment pipeline involves different docker contexts and build secrets that are not nearly as self-contained - not to mention actual build artifact dependencies.

I think the alluded to Docker example should be a big priority for the community to iron out.

For our use case, we have (multiple) different docker credentials for different deployments and want to contextually inherit these in all our of subsequent Docker build steps - it seems like we might just have to do prop drilling or adapt to a "dotenv per task" model (which sounds like a lot of dotenv loading).