Greg Roodt

It is a bit of a smell that bazel uses a stub that has a dependency on the host environment. Another workaround / hack to this on macos is to...

Thanks for the insight. In my opinion, it does seem like solving the "bootstrap problem" would be best solved in a way that doesn't involve the runtime itself due to...

@rickeylev Is a reasonable sketch of the problem this pseudo-code: `exec(runfiles-interpreter, ["the-thing.py"])` Bazel needs *something* to create a platform independent "exec" function (portable binary) without a runtime that can find...

I prefer a user-space solution, similar to this in the JVM ecosystem: https://github.com/johnynek/bazel_jar_jar I believe it's entirely reasonable to want to patch wheels (and possibly sdist), but Im not really...

Can you describe the use-case here? I'm not sure what this would be useful for.

Have you considered using rules_docker to package your application into a self-contained artifact for deployment to these platforms? It's also possible to bundle as a zip artifact. The platforms listed...

I had a look and GCP Dataflow also supports container images https://cloud.google.com/dataflow/docs/guides/using-custom-containers That would be more reproducible because what you build is what you run. This does sound like a...

It certainly seems to specify it will use the custom image for both the primary and worker nodes. From https://cloud.google.com/dataflow/docs/guides/using-custom-containers ``` When Dataflow launches worker VMs, it uses Docker container...

Apologies in advance for the potentially off-topic question. I am *really* optimistic about a world where it is possible to always install from `wheels`, even for packages which do not...

> I'd recommend doing something different: Thanks for the tip. Seems sensible! Is that going to be able to always build `wheels`, even if a package author doesn't setup their...