Comment by em-bee

18 hours ago

interesting, i am trying to install it to give it a try. the features in ttyphoon look very promising.

unfortunately the build now fails with "frontend.go:39:12: pattern all:frontend/dist: no matching files found"

i am also a bit taken aback by the many dependencies. with heightened risk of supplychain attacks and dependency failures that feels a bit scary.

> unfortunately the build now fails with "frontend.go:39:12: pattern all:frontend/dist: no matching files found"

How are you trying to build it? Are you calling make? Also what OS are you on?

    make build

> i am also a bit taken aback by the many dependencies. with heightened risk of supplychain attacks and dependency failures that feels a bit scary.

Yeah, I agree with you there. Most of my projects are very conservative with their dependencies; as was this one too, originally. But this project was just too large for one person to realistically manage on their own and without reusing the hard work of other libraries.

Unfortunately, the two libraries I need to lean on the most are exactly the kind of libraries that will have big dependency trees:

- GUI (Wails): just because there is a huge amount of code required to draw anything to screen

- AI (langchaingo/mcp-go): though mostly for tool use here but they’re optional

Both of these libraries were chosen because they are well maintained and have a high number of contributors/eyeballs On the code. But, as you said, the risk is still there.

  • i have fedora. and yes, i am running make build.

    why did you choose wails btw? did you look at fyne? it's go-native and it seems to have a lot less dependencies.

    can the AI integration be turned off? i am not going to use it myself.

    is there a chatroom where we can talk through debugging my build problem? github issues? you didn't turn in the discussion forum for ttyphoon like you did for murex. or is there another place where you hang out? hn is not exactly the ideal place to talk through dev issues.

    • An earlier build used SDL directly. There were reasons I didn’t choose Fyne and that was basically that the effort wasn’t much less than working directly with SDL due to various (potentially self imposed) constraints.

      I then switched to Wails because I wanted to add Markdown, Jupyter support. And other things too. Quickly I realised it was too much for me to attempt SDL (even just the markdown parser proved an annoying time sink) on my own. I think the terminal itself is worse for change so there might be a point when I revisit this switch and change my mind again.

      There was a brief period when both Wails and SDL were supported front ends. The idea being you could chose one based on a Go compiler tag. But that proved hard to maintain.

      There was also a time when the terminal was SDL and Wails just did the markdown stuff. They were different applications that passed messages via a rudimentary IPC. But that resulted in a multi-window hacky mess.

      So the current design is the compromise I’ve settled on but will likely change my mind at some point again.

      As for the AI, there isn’t any compiler flags to disable it. But it doesn’t work without you supplying an API key anyway. And the integration is just a few menu items so, hopefully, not intrusive. Which would also make it pretty easy to hide those options behind a compiler flag.

      I’m happy to chat as a GitHub issue if you’d prefer. I don’t hang out in may other places these days (time constraints)