task
task copied to clipboard
go-task
Add a "setup:" setting to allow running setup scripts before any command?
I'm looking for a tool that can run source venv/bin/activate and run the commands in that same shell. It is not cleanly doable using make, and so I tried Task.
It appears we can't do this using Task. Is there a way to have a workaround or add an option to run all commands in the same shell ?
Hi @jooola,
Can you explain more why you think this'd be useful? Perhaps an example...
When developing a Python project within a Virtual environment with all its dependencies, we always need to activate this virtual environment in order to run project tasks like testing, linting, building.
To set up the environment by hand, we run the following commands (where requirements.txt lists all the dependencies):
python3 -m venv venv
source venv/bin/activate
pip -q install --upgrade -r requirements.txt
Since the source command is altering the shell to activate it, we need to stay in it to execute the next commands. So I suggested to allow to run all the commands within the same shell.
The option should also all to run all the dependencies in the same shell.
Sorry for my previous message, I clearly wasn't describing my problem enough.
You can do this today as a multi-line command, but you need to somehow duplicate the setup of venv to each command, e.g. as a template variable, or just copy-paste, which ever is easier.
It would be something like this I guess ?
vars:
VENV: |-
test -d venv || python3 -m venv venv
source venv/bin/activate
tasks:
setup:
cmds:
- |
{{.VENV}}
pip -q install --upgrade -r requirements.txt
But dependencies inheritance cannot work in this case, that was the point of chaining dependencies. But this work around could work, I'll try it out. Thanks
👍
Remember to also add a set -e on of multi-line commands to ensure they exit on error.
vars:
VENV: |-
test -d venv || python3 -m venv venv
source venv/bin/activate
tasks:
setup:
cmds:
- |
set -e
{{.VENV}}
pip -q install --upgrade -r requirements.txt
But dependencies inheritance cannot work in this case, that was the point of chaining dependencies.
No it can't. Dependencies, or any other cmd, can never change the environment in task, which is what would be needed for that to work. The environment now, is evaluated/generated from scratch every-time before a task is run.
At an early stage of task, there was a "set" property, that could set the environment to the output of a command, but it was deprecated with good reason.
As @smyrman said, multi-line strings should solve this use case. The downside is that you have to concat the setup stage in each needed command.
Maybe we could add a setup flag to task/global to setup stuff before all commands?
version: '2'
setup:
- set -e
- rbenv init
tasks:
# ...
Sharing state between command calls for a single task would be possible, but it'd be likely confusing.
@andreynering https://github.com/direnv/direnv might be considered to achieve this? it actually load the sourced export values into its context. If so, can part of its code incorporated?
@stephencheng Interesting idea, worth studying the possibility. Thanks for sharing.
This is ideal but while we're waiting on this feature is there a file like ~/.bashrc that we can put functions in that we would like to be able to access globally from any task?
I really like the idea to allow a configurable list of commands to run before each shell task, set -e being an obvious use case.
Good point Sorin
On Tue, May 24, 2022 at 2:52 AM Sorin Sbarnea @.***> wrote:
I really like the idea to allow a configurable list of commands to run before each shell task, set -e being an obvious use case.
— Reply to this email directly, view it on GitHub https://github.com/go-task/task/issues/204#issuecomment-1135479827, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOJRHXKRV6A5CMUACUJFTIDVLR4CTANCNFSM4HNPTDIA . You are receiving this because you were mentioned.Message ID: @.***>
-- Regards,
Brian Zalewski (412) 345-3338
Idea: just like the setup: proposal above, having a cleanup: setting (needs to think if it's the best name) to run after each task could make sense as well.
#1115 is a complement to this. Both should probably be implemented together.
cleanup would be really great. My use case is that I need to do something like this:
tasks:
foo:
cmds:
- echo "do something"
preconditions:
- op document get "TLS Cert" --output=./test.crt --force && step certificate needs-renewal --expires-in 48h --bundle test.crt
This leaves a test.crt sitting around - I'll never want that after the task runs, so having some way to clean things like that up at the very end of task execution would be helpful! I'd definitely be able to use setup: as well.
