multiple paths per module

[eugenenelou]

Hi, Tach seems very nice, but I have a usecase where I want to regroup different python paths in a single module.

It's not possible now, but is it something that would make sense for Tach?

[emdoyle]

Hi @eugenenelou ! Thanks for raising this issue.

Right now it is a pretty core assumption that a Tach 'module' refers to a specific Python 'module' at runtime. Could you share more about your use case?

[eugenenelou]

Hi, I understand it's pretty core, but think one level of indirection by allowing to provide a mapping to convert a path to a module, decoupling both concept shouldn't break everything.

my usecase is that I have a monolith I want to modularize. We are using django with many django apps, and want several django apps to be grouped to form the modules. Because we don't want dozens of modules, but keep the number reasonable.

So right now to use Tach, we would have to define all the dependencies between each app in one of our module, creating a quadratic number of dependencies (and forcing us to script the generation of tach.toml). Whereas with the abstract module definition, it would just take one line per django app.

[emdoyle]

Ok that makes sense, it can definitely be awkward to set up a strict configuration on a large project from scratch. We actually explored the idea of 'tags' or 'layers' for this early on in the project, but the configuration at that point ended up being too complex - we will revisit this soon and see if there is a better way to integrate it, since others have asked for this as well.

In the meantime, there are maybe two features that could help you:

• tach sync: you may already know about this, but this should function as the 'script to generate tach.toml', at least initially
• unchecked modules: this is specifically to help folks incrementally adopt Tach by allowing you to specify a module without also checking its dependencies. This is to let you start with a subset of your Django apps being checked for example.

If those don't work for you, we are also currently piloting a web platform which turns a Tach config into a GitHub check which can incrementally check that incoming PRs respect module boundaries, even if the app as a whole is not in a passing state. Let me know if that sounds interesting!

[eugenenelou]

tach sync will only work when the dependencies are correct, otherwise it will just create a mess. I would prefer to first define the rule, and then fix the infractions it detects. We want to modularize the monolith, but we're not there yet.

[emdoyle]

That makes sense! We have seen some folks start by generating the mess, then marking anything unexpected/unwanted using 'deprecated'. This works a bit better when using the platform though.

I will take a closer look at what it would take to support this over the next couple of days. We already want to 'refresh' the tach mod and tach sync commands since there have been a lot of new features added since they were built. I think a better tach mod experience might be able to stand-in for tags by letting you easily manage many paths without having to manually edit the config.

Also, might be easier to continue this conversation on Discord but I will of course respond here as well.