sudoforge

For the record, it doesn't appear that `buildozer` supports reading from `stdin` anymore (I'm unsure if it ever did, except for the earlier comments in this thread): ``` ➜ buildozer...

Yeah, that and similar methods have been the only way to accomplish the goal here thus far. I haven't had time to work on the `__workspace__` implementation so far, but...

I have this issue and most definitely don't have any variance in my environment variables. I'm also using Bazel v1.2.1. Adding my [comment from another issue][0]: > Yeah, I have...

Thanks for opening an issue about this; it's been on my mind for some time. A few comments: > I tried: > > ``` > load("@com_github_bazelbuild_buildtools//buildifier:def.bzl", "buildifier_test") > > buildifier_test(...

If you really wanted to avoid the deprecation notice, you can save the patch file from that PR locally, and add it to your repository rule that fetches this workspace...

@alexeagle I've considered that too -- but I'm not sure that makes more sense than exposing the workspace path to the test sandbox, and I've gone back and forth on...

FWIW @brown, here's the visual difference between unified and non-unified diffs: ``` ➜ \diff {a,b}/README.md 1c1 < hello world --- > goodbye space ➜ \diff -u {a,b}/README.md --- a/README.md 2020-12-02...

Personally I specify `diff -urN --color` but that's because all of my host systems used GNU tools and I don't need to worry about any cross-compatibility issues. In a multi-user...

ignore the branch deletion; forgot to filter that out in a script that was deleting all non-head branches in my forks

Yeah, I have to agree that it's pretty annoying to have to wait for all 220+ protoc targets to build whenever the "sandbox goes stale" (I don't have metrics on...