heh. well, strictly necessary in the case of deploying a pants binary.

i just realized i disagree with the below but here's what i had typed i guess i mostly am attracted to the idea of a toolchain that "just works" everywhere because that in itself is cool. it also means we come in to the next phase, where we differentiate native build products through e.g. variants, with a deep understanding/codification of the various types of binary compatibility issues, which we wouldn't get if we just tossed an image out there. i also feel like if we can't solve this on the build side we're going to have a heck of a time on the consume side, where the problems are basically the same, unless we also just produce docker images or equivalent from our native code instead of shared libraries. i think seeing how effective pex is and how facebook has already tried out a major tool with FUSE (xar) the idea of providing some sort of stable environment sounds great -- as long as we can still produce shared libraries / etc so we can make e.g. conan packages. i view the current work as being solvable and having that done and making it work reliably gives us a basis for integrating new languages and workflows into native code. it feels to me like not solving this problem now means we'll have to solve it slowly, later, and the upfront work here feels like the right tradeoff (to me, right now).

but i actually don't think that tradeoff is really there because the problems we're solving right now are mildly to completely orthogonal

to actually consuming native artifacts

so it could be a great idea to sketch out how docker would work i could make a design doc

maybe at some point in the future a docker-assisted design would make sense. but right now it does not.

we have requirements both from customers and from our internal platform to not use docker for this.

beginning to dip a toe into it via the remoting API will make definite sense though, since the GCP implementation of the API supports them.

Who is the non-twitter "customer"

of remote execution?

or of native builds

No clue. You said: "we have requirements both from customers and from our internal platform to not use docker for this."

both of those are at twitter

ok - so just Twitter.

Thta's of course important and fine - but worth spelling

yes. it's somewhat implicit that if there were other folks interested in working on this, that would change the equation.

There has been alot of hoop-jumping in Travis to get the current impl working with old osx for example and it sounds like that has been artificial. I think twitter has a floor newere than our OSS floor

we have folks still running 10.11... stated minimum is 10.12

ok

but certainly the oss community might still be on 10.11...?

no clue

I have great disdain as you probably know for OSX support!

But clearly needed

yes. ...and actually a very valid reason not to be 100% reliant on docker for this.

(...as ludicrous as the OSX lockin is.)

Yeah, no love for docker. I'd just love to support images. That could be VMware (as supported by macstadium for example), or whatever other solution exists.

At least we don’t have to worry about Windows 😶

not yet. i’m tying to evangelize pants to my friend at facebook but he needs windows support for vr stuff. if we can’t cheat and just make everyone use the WSL from microsoft then i feel like that’s microsoft’s fault, as in, it may be possible we would never have to know or care about windows support at some point and still be able to run on it (which is neat)

@enough-analyst-54434 Probably bad thought: on my laptop a debug build of the rust is 4-6x faster than a release build. It's not obvious to me whether CI would end up faster or slower if we did debug builds there. Or less optimised release build. Definitely would mean those artifacts aren't releasable, though.

@wide-energy-11069 Bazel's view is super different internally and externally. Internally there is one platform, so native things Just Work, and anything that can be built from source is. Platform doesn't form part of a cache key because one platform. Externally, the approach is shrug work it out yourselves.