The same argument is made for not adhering to the XDG spec for user configuration files. The result is you have no real sense of specific locations for config files, shared static data, and app-generated data. If an app follows the spec you know exactly where to look. Otherwise it’s anyone’s guess.
I’ll admit this is less of a problem in project dirs, since tooling usually confines itself to a single file. But tooling outputs often similarly pollute. For example, I wish Python dumped its artifacts in a single directory I could delete, instead of in every source subdir.
> The same argument is made for not adhering to the XDG spec for user configuration files
I think it's a fundamental difference in that the project repo should be self-contained and "owned", whereas arbitrary software I run really shouldn't be putting files in my home directory.
In a software repo, anything inside it belongs to the project.
I think there are similarities -- the project's root is the project's, so why does eg the Travis CI system get to insist on having a config file sat in the project root?
Just like the gitlab-ci.yml, it handles things related to the whole repo, it basically runs a script in the root of the repo anyway.
Sure, supporting other paths is useful (eg. in case of a monorepo), but this default seems sane. Though I'm interested in where others move it, and why.
Since switching to git, I'm increasingly of the mind that clean) belongs to the source control (`git clean') rather than the build. After all, the source control knows what files belong to a bare checkout of the project and which have shown up since you got your grubby little paws on the code!
git clean has options to only clean ignored files, which generally does what you want. I could see there being weird situations where a file is .PRECIOUS (in make's terms) or where you have a file that's ignored but not a product of the build (a developer-specific config file?) where this doesn't work, but I haven't run into that yet, and it's freeing to not have to maintain a free target by hand.
I’ll admit this is less of a problem in project dirs, since tooling usually confines itself to a single file. But tooling outputs often similarly pollute. For example, I wish Python dumped its artifacts in a single directory I could delete, instead of in every source subdir.