I don't understand what problem this would solve...? What tools are affected by whether something is a Polylith repo or not?

Well, CIDER for example gets confused with too many deps.edns scattered all around. I mean this particular problem has a simple workaround and it's not a big deal. I'm just thinking in general, hypothetically, if someone for example decides to write some automation, wouldn't it be nice to quickly tell if the repo is polylith or not?

What do you mean by "CIDER for example gets confused with too many deps.edns scattered all around"?

(in VS Code/Calva when you jack-in, you sometimes have to tell it to use the workspace-level deps.edn file but that's expected in any repo that has multiple subprojects with deps.edn or project.clj files)

Unless you jack-in with CIDER at the root level, it may pick a deps.edn of a brick. That point was even debated here in the channel, there's a solution for it (I need to find it). I just want to make it work only with poly project. Like I said, not a huge deal. I just thought maybe there was some convention already to mark a repo as poly.

Like I say, Calva solves that by asking you which deps.edn to use instead of assuming...

the presence of workspace.edn is a good but not perfect indicator

i think the “solution” you’re referring to is one i posted , and yah jack-in it’s kind of annoying without it

Yes, I think I found your older post here in the channel. I just never found a moment to fix it in my config.

You know how it is? You can't even touch your .el files these days without someone complaining that Emacs constantly needs configuring. All the time.

@U0G75ARHC for sure, i actually reached 'fixpoint' on my emacs config, kind of bitter sweet, but i have I hard time figuring out how to improve it these days.