Skip to content
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

Closed
kethan1 opened this issue Jul 26, 2022 · 6 comments
Closed

Feature Request: OS Specific Tasks #83

kethan1 opened this issue Jul 26, 2022 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@kethan1
Copy link

kethan1 commented Jul 26, 2022

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 and unix_build.

My task looks like this:

[tool.poe.tasks.build]
shell = "unix_build"
interpreter = ["posix"]

However, there is no way to run windows_build on Windows instead of unix_build.

Potentially a syntax somewhat like this?

[tool.poe.tasks.build#linux,macos]
shell = "unix_build"
interpreter = ["posix"]

[tool.poe.tasks.build#windows]
shell = "windows_build"
interpreter = ["powershell"]
@kethan1 kethan1 changed the title Feature Request: OS Specific Tasks Feature Request: OS/Shell Specific Tasks Jul 26, 2022
@kethan1 kethan1 changed the title Feature Request: OS/Shell Specific Tasks Feature Request: OS Specific Tasks Jul 26, 2022
@nat-n
Copy link
Owner

nat-n commented Jul 27, 2022

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

[poe.tasks.build]
help = "build using the correct process for your platform"
"cmd#windows" = "..."
"cmd#macos,linux" = "..."

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:

  1. define a task per platform
  2. Use a shell (ie bash) task to execute different commands depending on the platform
  3. use a script task to manage platform detection and control flow in python

See previous discussion.

@kethan1
Copy link
Author

kethan1 commented Jul 27, 2022

Thank you for considering this feature. The syntax you proposed, or something similar to it, is excellent!

@nat-n nat-n added the enhancement New feature or request label Jul 27, 2022
@nat-n
Copy link
Owner

nat-n commented Aug 24, 2022

@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 switch task type that runs one task from a collection based on the captured result of another task.

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 control option contains the definition for a task, in this instance a script task that outputs the current platform. This output is captured and used to decide which of the tasked defined in the switch array to execute by comparing the captured output to the value of their case option.

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.

@kethan1
Copy link
Author

kethan1 commented Aug 26, 2022

I think that's a great idea that uses the toml structure quite nicely!

@nat-n nat-n self-assigned this Dec 22, 2022
nat-n added a commit that referenced this issue Dec 24, 2022
nat-n added a commit that referenced this issue Dec 24, 2022
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.
nat-n added a commit that referenced this issue Dec 25, 2022
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.
nat-n added a commit that referenced this issue Dec 25, 2022
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.
nat-n added a commit that referenced this issue Dec 25, 2022
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.
nat-n added a commit that referenced this issue Dec 25, 2022
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.
nat-n added a commit that referenced this issue Dec 26, 2022
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.
nat-n added a commit that referenced this issue Dec 26, 2022
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.
@nat-n
Copy link
Owner

nat-n commented Dec 26, 2022

@kethan1 This feature is now available as part of v0.17.0.

@nat-n nat-n closed this as completed Dec 26, 2022
@kethan1
Copy link
Author

kethan1 commented Dec 31, 2022

Just got a chance to look at the release, and the new feature solves my issue. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants