Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Tach – Visualize and untangle your Python codebase

github.com

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Show HN: Tach – Visualize and untangle your Python codebase

#41

Post by bmitc »

9question1 wrote: post #33
jlg23 wrote: post #28

Earlier quoted context omitted.

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.

This. It's ridiculous how often people complain about the design of free software. If you don't like it, just don't use it! Use something else! Build your own! Or fork it to work in the way you described that you'd prefer - you can do that yourself if you really want since the source is available

It's not complaining to provide critique, especially when the tool is being marketed and part of a technique to sell services.

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

Re: Show HN: Tach – Visualize and untangle your Python codebase

#42

Post by bmitc »

jlg23 wrote: post #28
byteknight wrote: post #25

Earlier quoted context omitted.

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.

This has nothing to do with being grateful or not.

Re: Show HN: Tach – Visualize and untangle your Python codebase

#43

Post by bmitc »

0x63_Problems wrote: post #15
bmitc wrote: post #14

Earlier 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…

To be clear, I'm not frustrated. Just providing feedback.

Re: Show HN: Tach – Visualize and untangle your Python codebase

#46

Post by globular-toast »

goosejuice wrote: post #36
globular-toast wrote: post #22

Earlier quoted context omitted.

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.

That says more about your process as a swe org than the technology you're using.

That you'd use a tool or a language to help you?

Re: Show HN: Tach – Visualize and untangle your Python codebase

#47

Post by globular-toast »

drdrey wrote: post #34

I would recommend installing it with uv tool install tach rather than pip install tach that way tach is installed system-wide but in its own isolated venv

I keep meaning to write a blog post about this. "pip install x" basically should be read as "this project is packaged and available on PyPI" rather than a literal installation instruction.

A seasoned Python developer will rarely, if ever, directly pip install something. Instead they would manually add it to pyproject.toml or, if they use something like poetry, use that to add it, or they'd use something like pipx to install it as a "global" tool (or just their system package manager). This has been true for years now. I think it's time projects stop writing "pip install x" and we come up with a standard way to say "the package name is x" and maybe a recommended installation method (like use uv/pipx to install as a system tool, or add to your project dependencies etc).

Re: Show HN: Tach – Visualize and untangle your Python codebase

#49

Post by rswail »

tracnar wrote: post #26
0x63_Problems wrote: post #23

Earlier quoted context omitted.

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.)

I always used to think of it as a module is a file `example.py`, a package is a directory `example` with a module `__init__.py`.

Re: Show HN: Tach – Visualize and untangle your Python codebase

#50

Post by bolognafairy »

0x63_Problems wrote: post #15
bmitc wrote: post #14

Earlier 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…

Since you’re being somewhat brigaded by the “everything local!” mob, I just wanna say that this all sounds completely reasonable to me. Some people hate being told that their demographic just isn’t currently being catered to exactly in the way that they want. I’m sure that these people working on things so utterly Top Secret can wait a while for your new little tool to support them. They’re just mad they can’t use it at Meta or whatever.
Post reply on HN