dubhash.d is always built in-place

[cmm]

[ I barely know any D, just tried to package serve-d for Nix and the rathole that opened up led me here ]

dubhash.d is built by a preCommand and there does not appear any way to tell the compiler where to put the compilation result, so it's built right there in the source directory. This is awkward for Nix packaging (at least the way I'm following at present), because the source directories of dub-fetched requirements are read-only.

[WebFreak001]

to properly work with read-only packages we would very likely need some changes in DUB or move away from the less error-prone automatic versioning approach to a manual one.

Would it be a solution if you could pass in an environment variable that makes dfmt/DCD/D-Scanner not attempt to write a hash file? (the dependencies shouldn't be used as executables then though, since they will be missing version information)

[cmm]

Or maybe just have the preCommand explicitly write whatever it writes to a location that is reasonably likely to be writable ($TEMPDIR, or the build directory according to DUB if that's knowable)?

[WebFreak001]

the build directory would be the best I think, since it is a build artifact after all, however DUB exposes no information about it to commands + we would also need it as string import path, so the compiler can actually read it, which is another thing that DUB doesn't give us. That's why I think we need to extend DUB here to actually be able to reliably and cleanly inject pre-generated stuff into the build, instead of the current "write somewhere in the package dir" approaches.

Outputting to $TMPDIR isn't really clean imo, since there is nothing that would clean it up reliably, except relying on the OS itself + this approach would be a no go as soon as we want to generate source code, since we would need to add TMPDIR as source folder, which would be a security risk, since it might be shared with other users and may contain source files that would get preferred over e.g. phobos, allowing other users to taint the built executable. Additionally TMPDIR isn't even portable on linux and would need a fallback to /tmp, which is not possible to express as (string) import path with the current DUB variable substitution.

I think we really need to separate how executable and libraries are built here as well, since when building an executable it's completely fine the way it is doing it right now. (although build directory would be nicer)