-
-
Notifications
You must be signed in to change notification settings - Fork 625
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal] Inline platform/arch key for commands #978
Comments
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 That said, since checking for OS/Arch is a very common scenario, I think maybe a prop like on: [windows]
on: [amd64]
on: [linux, darwin]
on: [windows/amd64] On a Taskfile: version: '3'
tasks:
build-windows:
cmds:
- go run windows.go
on: [windows] version: '3'
tasks:
build-windows:
cmds:
- cmd: go run windows.go
on: [windows] No strong vs. your proposal to have as keys, but I think the implementation of |
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? |
@leaanthony Yes, |
Renamed |
This is not enough, if or custom label is still needed. |
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:
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:
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:.desktop
file to the directoryFor 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:
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.
The text was updated successfully, but these errors were encountered: