translatenix

> I also think that unless there's a good use-case for accepting a directory in our CLI flag, let's go back to accepting just a cert bundle I think that...

> But I think let's follow their lead in this case, and make it a separate flag (I think maybe call it --ca-directory), which would also guard against unintentional configuration...

A pragmatic solution would be to allow `x: Listing = new Listing {...}` but not `x = new Listing {...}`. This would reflect the (current) reality that generics aren't reified....

Dealing with generics is never simple. Regarding your concrete arguments, `Listing.join` is defined for all `Listing`s, not just `Listing`. And IDEs could still try to infer the element type from...

I see no indication that `EvalTask` supports placeholders. It only accepts `RegularFileProperty getOutputFile()` and `DirectoryProperty getMultipleFileOutputDir()`, which clearly shouldn't contain placeholders.

This is a design mistake in `EvalTask`. Should try to fix that instead of making the task untracked.

I think `EvalTask` could have separate `Property` properties and invalidate outputs if those are set. But I see that `CliEvaluator` has `outputFiles` and `outputDirectories` properties, which might be all that's...

> Currently, there is a bug when mixing entries whose keys are integers with elements. So, the first snippet is incorrect, and is a bug. What does `[n] = x`...

> Although, it's not strictly necessary, the percent-encoding there is intentional (we are using java.net.URLEncoder underneath the hood to encode links and anchors). We should similarly run links from the...

@bioball Rebased and ready for review.