In short, we want to make the visualization UX as smooth as possible, and this is best done with a web app. The URLs use UUIDs, and the contents being sent don't include literal source code, only module names and Tach configuration. We will also delete graphs by UUID on request, and have done so in the past.

That said, we do try to be up-front about this, which is why that disclaimer exists, and when running this command on the CLI, you must supply an explicit `--web` argument to `tach show`. Otherwise, the default behavior is to generate a GraphViz DOT file locally.

Also, the mere fact that it sends any data, no matter what you say it contains is a non-starter at many places. And even module names can contain proprietary data.

Tach is an installable Python package, shipping a full web app would have to come in a separate form factor and has significant maintenance implications. Given we are explicit about the remote app before anything is sent, require explicit opt-in, and we provide usable alternatives locally, we prioritize shipping a useful graph experience that is immediately usable.

If you are at an enterprise that cannot tolerate this, then you can use a local viewer with either GraphViz DOT format or Mermaid which is generated by using `tach show` or `tach show --mermaid` respectively.

This is a (very) thinly veiled attempt at a closed garden of sorts, IMHO. Its a "clean" excuse for not giving away the milk for free, but it falls short on actual reasoning.

The default of the command is to generate locally. They don’t need to open source an entire web app. It’s easier to deploy themselves then deal with the burden of open sourcing and maintaining.

This isn’t some conspiracy. It’s a tiny startup trying to ship something useful.

The point of my post was to say why I'm not interested in using it.

still doesn't explain why you need to ship the data to a third party

> and this is best done with a web app

debatable. you could always write a GUI app. it's not that hard for such a self-contained project

there would be _a lot_ to gain from having this run totally locally without any network access and leaking source code to third parties.

beautiful HN comment. They might simply be familiar with web apps and want to focus on the part that provides the most value to users.

The external network requests are optional. It can run fully locally.

They’re a tiny startup that just launched, trying to ship something that helps people. Building a native app is not the most impactful thing they could spend their time on.

I’m mostly kidding but incidentally PHART was born in order to visualize Python dependency graphs in-line in 7-bit ASCII because I wanted the functionality in my dependency analyzing code summarizing concatenator tool I was using to aid in pair-programming with ChatGPT and Claude when codebases started outgrowing useful context lengths. That tool is here https://github.com/scottvr/chimeracat/ (it is nowhere as slick-looking as OP’s app, but also that is by design.)

The first time someone in public said they were curious to see the chimeracat output for his company’s codebase was also the first time I considered “wow.. how do I make sure people know they can trust chimeracat isn’t stealing their code?” and started thinking of ways to give people that surety and safety for any app, because so realized that though it was my first time to think about how “code analysis” tools like this, it even linters, prettifier’s etc. are a fertile ground for subterfuge and espionage, it was no doubt not the first time the thought had occurred elsewhere, and likely to at least a handful of folks who would (and no doubt are) putting such tools out there in the wild.