You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While ideally you shouldn't need to rely super heavily on activation scripts, sometimes it does become necessary or becomes sociologically a practicality to get work done with other people in your field. While it is quite nice that pixi already supports activation scripts, it would be useful if these could also be tied to tasks so that when using pixi run <task name> syntax you could ensure that particular setup steps are taken in the tasker runner subshell before task execution.
Aside: The activation script examples in the ROS 2 tutorial are pretty helpful for understanding how activation scripts work with environments.
pixidoes support activation scripts with [activation], but how would one write the TOML to specify an activation script for a specific task in an environment?
...
Are there any plans to implement something like this in the future? Or is this not a goal for the pixi task runners in general?
Originally posted by ruben-arts May 7, 2024
I could see support for that coming to the tasks yes, and it shouldn't be to hard as we already do the activation anyway.
The text was updated successfully, but these errors were encountered:
He @matthewfeickert, as shortly mentioned in the discussion, I believe this could complement the tasks as well.
[activation]
# currently available:scripts = ["env.sh"]
# In PR 1156 and not yet good enough env = { VARIABLE = "value" }
[tasks]
# currently available:start = { cmd = "echo $VAR", env = {VAR = "value"}}
# Logical next addition based on this conversation (note I'm not fond of the naming yet, please help):task_with_special_activation = { cmd = "python specialized_tool.py", env = { scripts = ["env.sh"]}}
Unfortunately our big inspiration Task doesn't have an activation script running field that we can learn from. So lets discuss some use-cases before we decide on the design.
Sorry to ignore this for a few weeks (I've had too much work travel). I also have not given this sufficient thought yet, but is task_activation too generic or confusing?
That could be a way of doing it! it just conflicts with the current implementation of env as we need to specialize the parser to find scripts and see it as a different thing then a normal variable. If you have more ideas keep them coming.
While ideally you shouldn't need to rely super heavily on activation scripts, sometimes it does become necessary or becomes sociologically a practicality to get work done with other people in your field. While it is quite nice that
pixi
already supports activation scripts, it would be useful if these could also be tied to tasks so that when usingpixi run <task name>
syntax you could ensure that particular setup steps are taken in the tasker runner subshell before task execution.Aside: The activation script examples in the ROS 2 tutorial are pretty helpful for understanding how activation scripts work with environments.
Discussed in #1323
Originally posted by matthewfeickert May 3, 2024
...
pixi
does support activation scripts with[activation]
, but how would one write the TOML to specify an activation script for a specific task in an environment?...
Are there any plans to implement something like this in the future? Or is this not a goal for the pixi task runners in general?
Originally posted by ruben-arts May 7, 2024
I could see support for that coming to the tasks yes, and it shouldn't be to hard as we already do the activation anyway.
The text was updated successfully, but these errors were encountered: