Open tommyalatalo opened 4 years ago
Hi @tommyalatalo, thanks for opening this issue!
I don't know if it'd be even possible to support that.
I'll keep this issue open for now, and give this some thought and experimentation once I have some available time.
Hi @tommyalatalo, thanks for opening this issue!
I don't know if it'd be even possible to support that.
I'll keep this issue open for now, and give this some thought and experimentation once I have some available time.
The problem in my original question is probably that the tasks are executed in separate shells, so the environment is reset for each following task. I think the solution to this would be similar to the directive that make has, called "ONESHELL".
I can't really say anything about whether or not this is possible to support or not, just that it would be really useful :)
version: '3'
vars: GREETING: hello
tasks: default: cmds:
For those interested, there's some ongoing discussion at #643.
I reached the same bug while trying to use nvm
inside task and I am aware that are few other popular tools that use shell functions instead of executables.
I know why it does not work but it still sucks as is far from obvious for the average user that these tools use shell functions, which are not directly executable. I wonder what we can do to improve the situation here.
What makes the situation even worse is that even $SHELL -c "nvm use node16"
did generate the same error, even if I did not expect that.
I fact I was not able to yet make use of nvm inside task to change the version of node being used. I need to create a setup of tasks like test-node12
, test-node14
,... for testing with different versions. Maybe someone has a working example.
A fantastic alternative to nvm
and other version managers is asdf
which doesn't use shell functions.
Asdf also supports setting a version for something specific to the shell instance.
asdf shell nodejs 16.15.1
Not really convinced on the fantastic side as I was not able to find even one use of asdf with taskfile so far, https://sourcegraph.com/search?q=context:global+file:%5ETaskfile%5C.yml+asdf&patternType=literal - not that nvm would be far away, with only one occurence, and that apparently broken for me.
Beautiful in fact. You don't need to actually do anything or specifically configure task. Just drop a .tool-versions
file in your repo (which is also automatically created/updated when running asdf local <tool> <version>
)
Not really convinced on the fantastic side as I was not able to find even one use of asdf with taskfile so far, https://sourcegraph.com/search?q=context:global+file:%5ETaskfile%5C.yml+asdf&patternType=literal - not that nvm would be far away, with only one occurence, and that apparently broken for me.
Often people (me, a lot) call scripts in the cmd:
field, which can then invoke an asdf
command.
I have a similar issue up (#1743) with a couple of use cases / examples to support investing in something to the effect of oneshell
directive.
I'm trying to set up nvm and node using go-task, but the gosh the tasks are running in is giving me some trouble.
You can see the task I'm trying to run below, where the first command works fine, $SHELL is zsh in my case, and the scripts installs correctly. But nvm is installed as a shell function, not a binary, so the commands "which nvm" and "nvm install node" fail to find "nvm".
nvm also adds some things to my .zshrc when the install script runs, and it requires to set some environment variables in order to immediately use nvm, or to restart your terminal to load those vars from .zshrc:
Is this possible to do with go-task or am I outside the scope of the application? It would be really great to be able to set this task up so that I can install nvm and node (npm) so that I can install some common tools that we use in one task. Would putting these installation commands for nvm and node into a script be a better approach?