-
-
Notifications
You must be signed in to change notification settings - Fork 63
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
Feature Request: OS Specific Tasks #83
Comments
Hi @kethan1, thanks for the feedback! You're not the first to ask about something like this, so it seems like something worth supporting, but I'll need to think through and experiment with the potential approaches a bit more to ensure the solution fits well, particularly because it might overlap with some work I'm planning on conditional tasks. Your idea of appending the OS requirement to the task name is interesting, although maybe appending it to the content key would work better (to avoid duplication/conflict of other task options) like
Although maybe using dot and underscore instead of hash and comma would be more toml friendly In the mean time a workaround could be one of:
See previous discussion. |
Thank you for considering this feature. The syntax you proposed, or something similar to it, is excellent! |
@kethan1 I have't had time to work on this yet, but I wanted to share an idea I had for how to serve this use case with a general purpose mechanism, by adding a new So for your use case it might look like: [tool.poe.tasks.build]
control.script = "sys:stdout.write(sys.platform)"
[[tool.poe.tasks.build.switch]]
case = "win32"
cmd = "..."
[[tool.poe.tasks.build.switch]]
# no case value defined means this is the 'default' case
cmd = "..." The What do you think? Personally I like that this is simple, generic and familiar, though it'll take a few tweaks to how tasks work make it work nicely. |
I think that's a great idea that uses the toml structure quite nicely! |
Also clean up documentation of task types.
Also: - make sys and os available in all script task expressions - refactor how named_args are accessed and added to the env - refactor how captured task results are stashed and accessed - clean up documentation of task types.
Also: - make sys and os available in all script task expressions - refactor how named_args are accessed and added to the env - refactor how captured task results are stashed and accessed - clean up documentation of task types.
Also: - make sys and os available in all script task expressions - refactor how named_args are accessed and added to the env - refactor how captured task results are stashed and accessed - clean up documentation of task types.
Also: - make sys and os available in all script task expressions - refactor how named_args are accessed and added to the env - refactor how captured task results are stashed and accessed - clean up documentation of task types.
Also: - make sys and os available in all script task expressions - refactor how named_args are accessed and added to the env - refactor how captured task results are stashed and accessed - clean up documentation of task types.
Also: - make sys and os available in all script task expressions - refactor how named_args are accessed and added to the env - refactor how captured task results are stashed and accessed - clean up documentation of task types.
Also: - make sys and os available in all script task expressions - refactor how named_args are accessed and added to the env - refactor how captured task results are stashed and accessed - clean up documentation of task types.
Just got a chance to look at the release, and the new feature solves my issue. Thank you! |
This is a feature request to enable different behaviors for a task depending on the OS it is running on.
My use case involves different arguments for a build system depending on the OS, but for the sake of simplicity the example will use two commands,
windows_build
andunix_build
.My task looks like this:
However, there is no way to run
windows_build
on Windows instead ofunix_build
.Potentially a syntax somewhat like this?
The text was updated successfully, but these errors were encountered: