https://pantsbuild.org/ logo
Join Slack
Powered by
<@U06A03HV1> do you think `platform` has enough in...
# development
h
@witty-crayon-22786 do you think 
platform
has enough information for local environment auto-detection? We only track OS family and arch, but not OS version for example.
w
“it’s a start”…
h
it is, but maybe painful to migrate if we realize it's not enough
w
we should assume that more information will be needed over time, but starting with the platform is a good place.
h
I suppose that we could always keep the 
macos_x86_64
as a catchall for 
macos_11.1_x86_64
and siblings
w
it suggests using either a dataclass or an expandable syntax… for example, python tags and rust triples are an expandable syntax for this a related use case
yea
f
I suggest we use platform triples since they've long been used by a lot of tooling.
👍 1
so there is a proof by usefulness by existence such that users should be familiar with them.
w
or something that can be expanded to target triples… i.e., if it doesn’t parse as a triple, it’s backwards compatible
f
well just translate the old syntax into the equivalent triple
w
yea.
h
this is the design doc for when @ancient-vegetable-10556 and I added arch to platform last year https://docs.google.com/document/d/1fFjMlQ7fLKsq3bomaoDoNgMxL2zMZPiqk0wjqZX8AFM/edit#
w
if we can avoid actually implementing triples yet, that would be ideal.
f
we could still do the translation but still only match the exact string of the triple
add the support for matching part of the triple at a later point
w
whatever is easiest and forwards compatible.
h
actually I don't see what the triplet would add here? It's the 
vendor
, right? What seems missing here is OS version number, for example, which triplets don't express
w
i suspect that keeping exactly the current syntax and confirming that it is not ambiguous with a triple will be the easiest thing. then can actually allow more of a triple to be specified later.
f
target triples would allow Pants on Windows to express the difference between the native Win32 toolchain and the GNU-based toolchain
w
the Environment itself will do that
…well, TBD.
f
I'm thinking more broadly. We may want Pants to eventually to be able to select a cross-compiler for invocation using normal local execution.
w
@fast-nail-55400: a user would do that explicitly by requesting an environment
f
(this gets back to the idea of introducing "toolchains" like Bazel has)
h
the Environment itself will do that
How so? Specifically what I'm envisioning is 
local_environment(comaptible_platforms=["macos_arm64"])
. Then Pants uses that to auto-detect which 
local_environment
to use Although we may want to give an option that people can set in 
.pants.rc
to force a certain 
local_environment
f
does the "environment" distinguish between a "host platform" and "target platform"?
or rather "execution" and "target" platforms
I may want to execute on darwin but target linux
i.e., cross-compile
w
@fast-nail-55400: afaict, Bazel is currently refactoring to remove that distinction: https://github.com/bazelbuild/bazel/issues/11432
h
@fast-nail-55400 thus far, you would do that by setting 
environment="my_docker_image"
. We rely on remote execution and/or Docker to do cross-platform stuff
w
my research on toolchains in the last few days suggested that they amount to a template for either a Subsystem or a Target.
the big unknown afaict is around how they are matched.
https://github.com/bazelbuild/bazel/issues/11432 is linked to a lot of relevant tickets: for example, it’s not currently possible to cross-build on macOS to Linux in docker, because the host/target platforms only allow for native crossbuilding (not for building in docker, for example)
ditto remote execution
my expectation of how a “native cross-build” (i.e. “build on Linux for macOS”) would work would be that you: 1. define an Environment which matches your Linux platform, but which sets up all of the relevant environment vars / paths / etc for a macOS build 2. then explicitly specify the “cross-build” Environment (on a 
cc_binary
, for example)
❤️ 1
💯 1
h
Nice, I like that. I will add to the user story. Also that just solved an issue I had with modeling 
local_environment
😄
w
um… yea. let’s just remember that most of these user stories are not in scope yet, heh.
but yea. as mentioned: whatever you think you can keep in your head without getting overwhelmed.
h
implementing, agreed. I would like to get the modeling right though
whatever you think you can keep in your head without getting overwhelmed.
with the key split of 
local_environment
vs 
docker_environment
, it's now easy to keep in my head 🙂
w
🤷
Open in Slack
PreviousNext
Powered by