[smohare]

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.

[Legogris]

> 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.

[pm215]

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?

[pas]

Where should it go?

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.

[dijit]

it's pretty common to have a .ci folder for your build scripts.

But nothing is fundamentally wrong either with XDG-esque directory structures.

.config/travis/

.ci/travis/

all the same to me, as long as it's consistent.

[rumanator]

> 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?

Because it defines the project's CICI pipeline? Aka how the project is built, tested, delivered, and deployed?

I mean, that's a more fundament part of the project than which files should be automatically ignored when committing stuff to git (i.e., .gitignore)

[wombatpm]

With 3.8 python has PYthoncacheprefix where you can specify where the pyc files end up. Makes life so much better with docker

[BerislavLopac]

Do you know about the pyclean tool?

[mauvehaus]

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.