BObognition·Aug 20, 2026Submission
2 points · Open discussiontach-org
tach
Rust2024–2026
tach-org / tach
tach
A Python tool to visualize + enforce dependencies, using modular architecture 🌎 Open source 🐍 Installable via pip 🔧 Able to be adopted incrementally - ⚡ Implemented with no runtime impact ♾️ Interoperable with your existing systems 🦀 Written in rust
Developer ToolsCommand LineLanguages & CompilersProductivityTesting & QualityDevOps & CloudLibraries & SDKs
7Distinct people
15Mentions
0Explicit recommenders
2.9KGitHub stars
What to know before exploring
What it is
A Python tool to visualize + enforce dependencies, using modular architecture 🌎 Open source 🐍 Installable via pip 🔧 Able to be adopted incrementally - ⚡ Implemented with no runtime impact ♾️ Interoperable with your existing systems 🦀 Written in rust
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month15 dated mentions
Observed mentions: 2024-02-14 17:05:04 UTC to 2026-08-20 15:48:49 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Feb 2024 | 2024-02-01 00:00:00 UTC | 2024-03-01 00:00:00 UTC | 2 | 2 | 0 |
| Mar 2024 | 2024-03-01 00:00:00 UTC | 2024-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2024 | 2024-04-01 00:00:00 UTC | 2024-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2024 | 2024-05-01 00:00:00 UTC | 2024-06-01 00:00:00 UTC | 3 | 0 | 3 |
| Jun 2024 | 2024-06-01 00:00:00 UTC | 2024-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2024 | 2024-07-01 00:00:00 UTC | 2024-08-01 00:00:00 UTC | 2 | 1 | 1 |
| Aug 2024 | 2024-08-01 00:00:00 UTC | 2024-09-01 00:00:00 UTC | 2 | 2 | 0 |
| Sep 2024 | 2024-09-01 00:00:00 UTC | 2024-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2024 | 2024-10-01 00:00:00 UTC | 2024-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2024 | 2024-11-01 00:00:00 UTC | 2024-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2024 | 2024-12-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2025 | 2025-01-01 00:00:00 UTC | 2025-02-01 00:00:00 UTC | 1 | 0 | 1 |
| Feb 2025 | 2025-02-01 00:00:00 UTC | 2025-03-01 00:00:00 UTC | 2 | 1 | 1 |
| Mar 2025 | 2025-03-01 00:00:00 UTC | 2025-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2025 | 2025-04-01 00:00:00 UTC | 2025-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2025 | 2025-05-01 00:00:00 UTC | 2025-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2025 | 2025-06-01 00:00:00 UTC | 2025-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2025 | 2025-07-01 00:00:00 UTC | 2025-08-01 00:00:00 UTC | 0 | 0 | 0 |
| Aug 2025 | 2025-08-01 00:00:00 UTC | 2025-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2025 | 2025-09-01 00:00:00 UTC | 2025-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2025 | 2025-10-01 00:00:00 UTC | 2025-11-01 00:00:00 UTC | 1 | 0 | 1 |
| Nov 2025 | 2025-11-01 00:00:00 UTC | 2025-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2025 | 2025-12-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2026 | 2026-01-01 00:00:00 UTC | 2026-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2026 | 2026-02-01 00:00:00 UTC | 2026-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2026 | 2026-03-01 00:00:00 UTC | 2026-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2026 | 2026-04-01 00:00:00 UTC | 2026-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2026 | 2026-05-01 00:00:00 UTC | 2026-06-01 00:00:00 UTC | 1 | 0 | 1 |
| Jun 2026 | 2026-06-01 00:00:00 UTC | 2026-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2026 | 2026-07-01 00:00:00 UTC | 2026-08-01 00:00:00 UTC | 0 | 0 | 0 |
| Aug 2026 | 2026-08-01 00:00:00 UTC | 2026-09-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
15 sourcesAlthough it's not part of core Python, tach is pretty handy for specifying and enforcing those larger-scale interactions: https://github.com/tach-org/tach
In If AI writes your code, why use Python?Tach, mentioned in the article, seems to be in maintained. But I dug around and found this comment:
https://github.com/gauge-sh/tach/issues/791#issuecomment-338...
> since nobody else has done it yet, i've forked tach and updated it to work on python 3.14 - https://github.com/DetachHead/dtach
In Why is everything so scalable?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.
In Show HN: Tach – Visualize and untangle your Python codebaseShow HN: Tach – Visualize and untangle your Python codebase
Hey everyone! We're Evan and Caelean, the authors of Tach.
Tach lets you visualize the architecture of your Python codebase, and gives you the tools to incrementally improve it. It uses module boundaries to give teams the benefits of microservices without the deployment complexity.
If your code has been getting tangled up as your team and codebase grows, Tach helps you move back in the right direction, incrementally and quickly. You can use Tach to incrementally adopt a "modular monolith" architecture [1], for better local reasoning and smoother feature development.
Since our last Show HN (https://news.ycombinator.com/item?id=41359181) we've shipped support for layers, third party dependencies, visualizations, and more.
Tach is: * Open source (MIT) * completely free * fast (written in Rust) * in use by teams at NVIDIA, PostHog, and more.
Read the rest
One way Tach differs from existing systems that handle this problem (build systems, import linters, etc) is the ability to be incrementally adopted. Also, runtime speed.
If you struggle with dependencies, onboarding new engineers, or a massive codebase, Tach is for you! We built it with developers in mind - with clean integrations into Git, CI/CD, and IDEs, and the performance for it to be effective in any form factor.
[1] https://www.milanjovanovic.tech/blog/what-is-a-modular-monol...
I'm very impressed by the recent developer experience improvements in the python ecosystem. Between ruff, uv, and https://github.com/gauge-sh/tach we'll be able to keep our django monolith going for a long time.
Any opinions about the current state of the art type checker?
In Ruff: Python linter and code formatter written in RustShow HN: Strict interfaces and dep management for Python, written in Rust
Tach is a pip package that lets you define module boundaries, automatically detect all cross-module dependencies, and then validate and enforce those dependencies.
It also supports strict interfaces for modules by overloading `__all__`.
The core static analysis is done in Rust, so all Tach commands run quickly.
The goal of Tach is to help eng teams maintain velocity while scaling quickly, something we've seen break down a number of times. Give it a try!
68 points · Open discussionShow HN: Tach – fast Python import linter in Rust with monorepo support
Tach lets you define module boundaries in a Python monorepo, automatically detect all cross-module dependencies, and then validate those dependencies. If ‘billing’ shouldn’t depend on ‘core’, you can enforce that with Tach.
You can also visualize your module graph, and use it for selective testing - running tests only on the modules impacted by your changes.
The core static analysis is done in Rust, so Tach is quick enough to be part of local development.
We’re building Tach to help engineering teams maintain velocity while scaling a monorepo. We’d love for you to give it a try!
4 points · Open discussionBazel (originating from Blaze inside Google) is great but very heavy/takes a lot of work to adopt. It's likely the gold standard if you're working with a large polyglot repo.
As a python dev, I've been frustrated with existing solutions, which is why we built Tach to solve some of the problems we've faced, particularly around organization and isolation - https://github.com/gauge-sh/tach
Pants is another great build system out of Twitter that has seen widespread adoption - https://www.pantsbuild.org/
In Ask HN: Best Tools for Monorepo?Tach – A Python tool to enforce dependencies, written in Rust
1 points · Open discussionTypically teams won't have access to the code that's being deployed on the other side of the network boundary. This physical separation is overkill though; something like CODEOWNERs and https://github.com/gauge-sh/tach can do this without incurring remotely the same overhead.
In Don't microservice, do moduleWe've encountered the exact same problem in the past, and open sourced our solution to enforce those boundaries! https://github.com/gauge-sh/tach Alongside CODEOWNERs, you can effectively constrain teams to focus on where they need to be.
In Don't microservice, do moduleWe can enforce module boundaries in code with tooling.
An example for Python: https://github.com/gauge-sh/tach
In Don't microservice, do moduleShow HN: Modguard – a lightweight Python tool for enforcing modular design
Hi HN!
We are excited to show you modguard - a Python tool we built to enforce a modular, decoupled package architecture.
We built modguard to solve a recurring problem that we've experienced on software teams - code sprawl. Over time, cross-module imports would tightly couple together what used to be independent domains, and eventually create "balls of mud". This made it harder to test, and harder to make changes. Mis-use of modules which were intended to be private would then degrade performance and even cause security incidents.
This would happen for a variety of reasons:
- Junior developers had a limited understanding of the existing architecture and/or frameworks being used
- It's significantly easier to add to an existing service than to create a new one
- Python doesn't stop you from importing any code living anywhere
- When change
Read the rest
s are in a 'gray area', social desire to not block others would let changes through code review
- External deadlines and management pressure would result in "doing it properly" getting punted and/or never done
Attempts to fix this problem always came up short. Inevitably, standards guides would be written, and stricter attempts would be made to enforce those guides. Teams would lead developer education efforts, and restrict code review. These approaches each had their own flaws, and didn't scale.
The solution is to explicitly define a module's boundary and public interface in code, and enforce those domain boundaries through CI. This means that introducing a new cross-module dependency required explicitly changing the public interface or the boundary itself. This is a significantly smaller and well-scoped set of changes that can be maintained and managed by those who understood the intended design of the system.
modguard is:
- fully open source
- able to be adopted incrementally
- implemented with no runtime footprint
- a standalone library with no external dependencies
- interoperable with your existing system (cli, generated config)
We hope you try it out! We’d love your feedback.
Github - https://github.com/Never-Over/modguard
Docs - https://never-over.github.io/modguard/
admin@0x63problems.dev
Show HN: Modguard – Enforce modular Python automatically
Hi HN!
We are excited to show you modguard - a Python tool we built to enforce a modular, decoupled package architecture automatically.
We built modguard to solve a recurring problem that we've experienced on software teams - code sprawl. Over time, cross-module imports would tightly couple together what used to be independent domains, and eventually create "balls of mud". This made it harder to test, and harder to make changes. Mis-use of modules which were intended to be private would then degrade performance and even cause security incidents.
This would happen for a variety of reasons:
- Junior developers had a limited understanding of the existing architecture and/or frameworks being used
- It's significantly easier to add to an existing service than to create a new one
- Python doesn't stop you from importing any code living anywhere
Read the rest
- When changes are in a 'gray area', social desire to not block others would let changes through code review
- External deadlines and management pressure would result in "doing it properly" getting punted and/or never done
Attempts to fix this problem always came up short. Inevitably, standards guides would be written, and stricter attempts would be made to enforce those guides. Teams would lead developer education efforts, and restrict code review. These approaches each had their own flaws, and didn't scale.
The solution was to explicitly define a module's boundary and public interface in code, and enforce those domain boundaries through CI. This meant that introducing a new cross-module dependency required explicitly changing the public interface or the boundary itself. This was a significantly smaller and well-scoped set of changes that could be maintained and managed by those who understood the intended design of the system.
modguard is:
- fully open source
- able to be adopted incrementally
- implemented with no runtime footprint
- a standalone library with no external dependencies
- interoperable with your existing system (cli, generated config)
We hope you try it out! We’d love your feedback.
Github - https://github.com/Never-Over/modguard
Docs - https://never-over.github.io/modguard/
admin@0x63problems.dev