Does this work together with uv?
Show HN: Tach – Visualize and untangle your Python codebase
21–30 of 63 posts
Re: Show HN: Tach – Visualize and untangle your Python codebase
#22Earlier quoted context omitted.
> 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…
The conventions are widely used and Python is used successfully in numerous “large monoliths”. Saying that the conventions may as well not exist if they’re not enforced is demonstrably nonsense.
It depends on your team. If the whole team "gets it" then things will be fine. But if you've got a team with juniors or people happy to do whatever crap they or ChatGPT can come up with to make things work then it doesn't.
Re: Show HN: Tach – Visualize and untangle your Python codebase
#23When I tried it, it seemed like you really need to list all modules in `tach.toml`. What 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?
This should definitely be supported out-of-the-box, we can take a closer look in Discord or through GH Issues! But generally I would expect:
```
[[modules]]
path = "foo"
depends_on = []
[[modules]]
path = "bar"
depends_on = ["foo"]
```
would do the trick, assuming both are within a configured source root, and their children are _not_ also marked as modules. If the children are marked as modules, their dependency rules are treated separately and wouldn't automatically inherit from a parent.
Re: Show HN: Tach – Visualize and untangle your Python codebase
#24Does this work together with uv?
Yes!
Here is an example project that is configured as if it were a uv workspace: https://github.com/gauge-sh/tach/tree/main/python/tests/exam...
In that project, `tach check-external` would handle between-workspace dependencies, while the core `modules` and `interfaces` config would handle within-workspace dependencies.
Soon these will be better unified, we kept the 1st-party/3rd-party distinction separate while we learned what the UX should be.
Re: Show HN: Tach – Visualize and untangle your Python codebase
#25Earlier 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…
I appreciate the attempt but the reasoning of "it requires maintenance" is entirely moot. You have to do this regardless. Its just whether or not you publish it open-source. You are still saying, internally, this is good enough for customers, when you push it out.
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.
Re: Show HN: Tach – Visualize and untangle your Python codebase
#26When I tried it, it seemed like you really need to list all modules in `tach.toml`. What 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?
This should definitely be supported out-of-the-box, we can take a closer look in Discord or through GH Issues! But generally I would expect: ``` [[modules]] path = "foo" depends_on = [] [[modules]] path = "bar" depends_on = ["foo"] ``` would do the trick, assuming both are within a configured source root, and their children are _not_ also marked as modules. If the children are marked as modules, their dependency rule…
Ok great, I indeed just tried, I might just have been confused last time! Maybe you could mention in the doc that a module can be a "package"? (Even though I suppose a package is also a module, I always find the Python terminology a bit confusing there.)
Re: Show HN: Tach – Visualize and untangle your Python codebase
#27Earlier quoted context omitted.
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…
I appreciate the attempt but the reasoning of "it requires maintenance" is entirely moot. You have to do this regardless. Its just whether or not you publish it open-source. You are still saying, internally, this is good enough for customers, when you push it out. 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…
I am having an allergic reaction too, I don't see any reason this should exfiltrate any information from my machine.
Re: Show HN: Tach – Visualize and untangle your Python codebase
#28Earlier quoted context omitted.
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…
I appreciate the attempt but the reasoning of "it requires maintenance" is entirely moot. You have to do this regardless. Its just whether or not you publish it open-source. You are still saying, internally, this is good enough for customers, when you push it out. 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…
Looking at the license (MIT) we already got much more than what we paid for and the authors don't "have to" do anything but accept thanks of those who chose to be grateful for software they got for free.
Re: Show HN: Tach – Visualize and untangle your Python codebase
#29Really 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…
> we want to make the visualization UX as smooth as possible
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.
Re: Show HN: Tach – Visualize and untangle your Python codebase
#30Having the example be a video that changes was confusing at first, and if you are going to show me something that is changing, I would like to be able to rewind to the beginning. But really I just think it's a bad idea to show something like that without making it obvious what it is.
What do you mean by "a video that changes"?
I liked the video-example, it's way better than examples in many projects that use just text, when the tool does something quite complex that better be demonstrated in a video with a narrator explaining what's happening and why.