Douwe Osinga
Douwe Osinga
going to close this due to not being able to reproduce
we have the building blocks to make this work, actually. the way that goose works is that there is a "server" process and the desktop client. if you could run...
I thinK @eduardolat that's what @jamadeo is describing more or less. the difference being that in his suggestion the extension itself would run in the container and just get instructions...
So I don't think you can run ollama on the windows side of things and goose in WSL. you can now run Goose direclty on the windows command line though,...
hmm, this seems strange can you run something like this: ``` /usr/lib/.build-id/0f/29d6c2dfb6d4f33e75298c2493b77504fb6d9a ``` to get more info about that file? and then: ``` rpm2cpio ./Goose-1.12.1-1.x86_64.rpm | cpio -idmv find ....
thinking about this, it could just be uvx that we bundle.
I don't know that we should be doing this. I would invest in better search instead
The real solution here is a I guess to make the bash tool treat every different shell command as its own tool.
do we still want to get this in? @lifeizhou-ap if so can you have a look?
you can do this using the GOOSE_PATH_ROOT environment variable. normally goose will store settings in .local/... but if you set that variable, you can get the whole config/logs/etc be somewhere...