For tool configs? I’m not really sure I follow. All my source code for the project goes in src/
or some other subdirectory, and the project root is a bunch of configs, a source directory, maybe some scripts, etc. It’s never really bothered me.
What has bothered me is __pycache__
directories. Whoever decided to litter those in every source directory all over the place… let’s just say I hope they learned to never do that again. I deal with enough trying to get Python to work at all (with the absolute hell it is to get imports working correctly, the random, but admittedly mostly documented, BS gotchas littered all over the standard library, packages with poor docs, no types, and every function worth calling taking **kwargs
, etc). Seeing my code littered with these directories isn’t something I really want to deal with as well.
A standard for build output might make sense to me. Maybe just throw cache stuff in .cache
and build output to .build
(with intermediate artifacts in there as well potentially). For configs, I wouldn’t really complain about it all going in .config
, but it also doesn’t matter much to me, and sometimes you end up having nested configs anyway in nested project dirs (thinking of eslint configs, gitignores, etc).
These things take an order of magnitude more companies today to build. Not only could 300 people not build the board inside one of the machines used for manufacturing, but 300 companies of hundreds to thousands of employees couldn’t either. Each component is usually created by one company that specializes in that specific component and only that component because of how complex these things are to manufacture individually.
For that to work, you’d need villages to specialize in what they produce and export, but then this leads to a completely different kind of society than what you two are discussing here.