Show HN: Tach – Visualize and untangle your Python codebase
11–20 of 63 posts
Re: Show HN: Tach – Visualize and untangle your Python codebase
#12This looks nice! I vaguely know Grimp as a similar tool, any idea how they differ/compare?
Tach is also more opinionated - so it doesn't require you to write any custom code, and uses declarative config to enforce your desired architecture.
Re: Show HN: Tach – Visualize and untangle your Python codebase
#13Tools like this rub me the wrong way. We have well established conventions like prefixing private modules and symbols with an underscore, or declaring your public interfaces in the __init__.py file, but the Python developer decries it as "busywork", "weird" and "hard to read", so we instead use tools like this. We can manage dependencies with protocols, a type checker and generally following SOLID principles, but the…
The language doesn't enforce them, so they may as well not exist. See: python dependency management.
> This is more commentary on the Python developer than this tool.
100%. Python has become an unstructured Wild West, perhaps even worse than modern JavaScript. The "Zen of Python" is a bold faced lie.
Python has incredible use cases. It blends together different disciplines effectively. But perhaps we should ask ourselves whether or not it's a language suitable for writing large monoliths in.
Re: Show HN: Tach – Visualize and untangle your Python codebase
#14Really excited to see this project gain traction. > Note that this graph is generated remotely with the contents of your `tach.toml` Isn't shipping off parts of your codebase to a 3rd party without warning in the CLI a security risk? Or in regulatory environments you get audited that your code was only stored on properly vetted services which is why some sales cycles for AI coding assistant tools are so long. It woul…
Co-author here, fair question! 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 ex…
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.
Re: Show HN: Tach – Visualize and untangle your Python codebase
#15Earlier quoted context omitted.
Co-author here, fair question! 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 ex…
Why not just let users run the web app locally? There's no reason it needs to be remote. 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.
Re: Show HN: Tach – Visualize and untangle your Python codebase
#16Tools like this rub me the wrong way. We have well established conventions like prefixing private modules and symbols with an underscore, or declaring your public interfaces in the __init__.py file, but the Python developer decries it as "busywork", "weird" and "hard to read", so we instead use tools like this. We can manage dependencies with protocols, a type checker and generally following SOLID principles, but the…
> We have well established conventions like prefixing private modules and symbols with an underscore, or declaring your public interfaces in the __init__.py file, The language doesn't enforce them, so they may as well not exist. See: python dependency management. > This is more commentary on the Python developer than this tool. 100%. Python has become an unstructured Wild West, perhaps even worse than modern JavaScri…
Re: Show HN: Tach – Visualize and untangle your Python codebase
#17Tools like this rub me the wrong way. We have well established conventions like prefixing private modules and symbols with an underscore, or declaring your public interfaces in the __init__.py file, but the Python developer decries it as "busywork", "weird" and "hard to read", so we instead use tools like this. We can manage dependencies with protocols, a type checker and generally following SOLID principles, but the…
> We have well established conventions like prefixing private modules and symbols with an underscore, or declaring your public interfaces in the __init__.py file, The language doesn't enforce them, so they may as well not exist. See: python dependency management. > This is more commentary on the Python developer than this tool. 100%. Python has become an unstructured Wild West, perhaps even worse than modern JavaScri…
I see your point. You can enforce them with mypy by declaring your exports in your __init__.py file, using the `as` aliasing method or using `__all__`: https://mypy.readthedocs.io/en/stable/command_line.html#cmdo....
Re: Show HN: Tach – Visualize and untangle your Python codebase
#18What I wanted was to work at a coarser package level. For example if you have the modules `foo.a`, `foo.b`, `bar.a`, and `bar.b`, I'd like a rule that `bar` can import from `foo` but not vice versa, without having to list or care about the submodules.
Is that something you'd want to support?
Re: Show HN: Tach – Visualize and untangle your Python codebase
#19Earlier quoted context omitted.
Why not just let users run the web app locally? There's no reason it needs to be remote. 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.
I can understand the frustration, but I think there are legitimate reasons to run this remotely. 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…