Alexandre Archambault

> @alexarchambault Can you please comment, if there are any reasons to not vendor the test metadata into this repository? I'm speaking about [test-metadata](https://github.com/coursier/test-metadata) and [handmade-metadata](https://github.com/coursier/handmade-metadata). IIRC, [test-metadata](https://github.com/coursier/test-metadata) is managed...

About directories and windows-ansi, as I commented on https://github.com/coursier/coursier/pull/2986, these can be used as standard dependencies now (except [coursier/directories-jvm](https://github.com/coursier/directories-jvm) needs to be published to Maven Central)

[Several people](https://github.com/coursier/test-metadata/graphs/contributors) sent contributions involving that repository in the past, there's nothing insurmountable here. It could be documented more, maybe even in a `pull_request_template.md` that GitHub shows everytime users open...

> Since just using some random cli tools may not respect the file structure of the coursier cache Do you have specific tools in mind? The coursier cache is meant...

I wish there was a way to remove stale artifacts (and reclaim disk space), but I've not been able to think of a reliable or good-enough way to do so....

But keeping only the latest versions of things might be useful to some users

> Can't we record the fetch/download timestamp somehow and use this? I mean, if the last modified times are the ones from the original repositories, we could just write some...

> Without cleanup support any coursier cache will be sooner or later "written to" by external tools. The most trivial tool might be `rm -r`, which is probably the only...

@som-snytt I often do that in practice too. Setting `COURSIER_CACHE` in the environment should work for all apps / libraries using coursier.

Something's wrong… 🤔