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).
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).
When enabled via flag, dotnet puts stuff into artifacts/obj, artifacts/bin, and artifacts/publish respectively. I like that. So much better than every proj folder having their own.
And there’s really no need to make it a dot folder. For the publish you don’t want to anyway. And you may want to navigate to bin as well, to run a build or inspect the output.
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
.cacheand 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).When enabled via flag, dotnet puts stuff into
artifacts/obj,artifacts/bin, andartifacts/publishrespectively. I like that. So much better than every proj folder having their own.And there’s really no need to make it a dot folder. For the publish you don’t want to anyway. And you may want to navigate to bin as well, to run a build or inspect the output.