Repository navigation
[Proposal] Inline platform/arch key for commands #978
Description
Firstly, thanks for such an awesome project!
I've been trying to write a simple taskfile that does slightly different things depending on platform/arch. This has led me to try the 2 current methods for doing this:
- Go Template method
- Multiple Taskfiles
The first is hard to read and I had issues with it outside of simple echos (easy to make invalid YAML). For multiple platforms, this would get messier:
- echo '{{if eq OS "windows"}}windows-command{{else}}unix-command{{end}}'
The second option can lead to many Taskfiles on disk making it harder to manage.
As an example scenario, I want to run a go build on linux, darwin & windows but need to do slightly different things on each:
- On Windows, generate a .syso file
- Run go build
- On Darwin, create an app structure
- On Darwin, copy the app to the app structure
- On windows, copy the correct 3rd party dll for the architecture
- On linux, copy a
.desktopfile to the directory
For the templating option, Taskfile.yaml would be very messy and I'm not even sure it's achievable in any elegant way.
The multi-taskfile option would be better IMHO, but now there's potentially 4 task files and 1 main.go file which seems overkill, not to mention code duplication. I mean it's possible but....
When I break down the problem, I simply want to be able to run certain commands on certain platforms within a task. This led me to think about an alternative approach:
For a cmd, allow the following syntax: - [platform/arch:] command
Example:
version: '3'
tasks:
build:
cmds:
- darwin: mkdir -p x/y/z
- windows: winres -I app.manifest -o app.syso
- go build
- windows/386: copy ..\32bit\app.dll .
- windows/amd64: copy ..\64bit\app.dll .
- linux: cp ../app.desktop .
I've created a PoC and it's a reasonably simple change and works well. I'm not well-versed in Task and the nuances this may introduce so I thought I'd put it out there and see what people think. If there's agreement that it's a good addition, I'll create a PR so I can get feedback on the best way to implement it.
Cheers.
Activity
andreynering commentedon Jan 5, 2023
Hi @leaanthony!
I agree that we can improve this use case. Needs a bit of discussion on how, though.
I'm curious to see your PoC work. If you could push it to a branch in your fork, or create a PR (whatever you prefer), so I can take a look, that would be helpful!
FYI, we have an open (and overdue) issue about having an
ifattribute able to control when a task/cmd will run: #608. That's a more generic solution, but would help in this use case.That said, since checking for OS/Arch is a very common scenario, I think maybe a prop like
on: [...]should be much cleaner:On a Taskfile:
No strong vs. your proposal to have as keys, but I think the implementation of
on:would probably be easier and more generic, avoiding the need of declaring keys for each OS/Arch combination on the YAML definition.leaanthony commentedon Jan 5, 2023
Thanks @andreynering for your time in replying. I like your proposal to use the "on" keyword. I knocked up a quick PR to achieve this. I'm sure there's plenty wrong with it but it does work and makes quite a good starting point. Any feedback welcome!
One thought: the word "On" to me implies triggers/events, almost like a pre-requisite. Would the word "platforms" be better in this case?
andreynering commentedon Jan 5, 2023
@leaanthony Yes,
onwas my initial thought, but I'm open to ideas.platformsseems much better, indeed.leaanthony commentedon Jan 5, 2023
Renamed
On->Platformsand updated PR. I wasn't sure how to test using the testdataTaskfile.ymlI've added other than manually, without a bunch of "if I'm running on OS A then expect result B" type commands. Thoughts?ccxuy commentedon Oct 11, 2024
This is not enough, if or custom label is still needed.
There are many different platform or OS, or self-maintain server settings, the workflow need to deal with different situation.