Hacker News Reader

Comment by throwaw12 | Hacker News Reader

I havent used nor gondolin neither docker's solution, but curious to know what gondolin is missing (evaluating both for my personal use)? is it only the DX or something else, if DX, can you what exactly is missing?

thanks

View on HN

In my experience it's mostly the UX/DX where Gondolin is lacking. For instance, I don't want to set up a JavaScript project every single time I need a sandbox. Instead, I just want to place a config file somewhere in my repo or my home dir and be done with it.

So I wrote a wrapper around Gondolin which allows me to do that and a few other things: https://github.com/codethief/tuor

(Warning: Still very much experimental / underdocumented.)

If you'd be open to trying something else, my startup is open core: https://github.com/gofixpoint/amika

The definition for your cloud sandboxes is just a TOML config in your repo

We also have an API and CLI to let users message the agent from outside or across sandboxes

We're still building a lot, so if you have any time to try it out (amika.dev) and give feedback, that is worth gold to us!

I'm afraid I don't want my sandboxes to live in the cloud, though. :-)

Yes, the stated "target workload"[0] is not what i'm looking for. I want my agent to run for long, spin up dedicated local stack while developing etc.

It seems with gondoling i need to explain the agent to run commands in the sandbox, but then where does the agent run itself?

[0]: https://earendil-works.github.io/gondolin/workloads/

You can run the agent in the gondolin sandbox if you wish.

Their example implementation with pi uses a pi extension so that pi runs on the host but the read/write/bash/etc tools run in the guest. Doesn’t have to be that way though.

Note that the pi-extension example in the gondolin repo is very outdated. Look in the pi repo instead.

https://github.com/earendil-works/gondolin/issues/115 for once

Reply on news.ycombinator.com