hundreds-father-40408/25/2022, 4:35 PM
sparse-lifeguard-9573708/25/2022, 4:41 PM
wide-midnight-7859808/25/2022, 4:47 PM
sparse-lifeguard-9573708/25/2022, 4:48 PM
docker run ….. ./pants <goal>
in a container, but I do want to run `test`s and
targets in one
wide-midnight-7859808/25/2022, 4:50 PM
sparse-lifeguard-9573708/25/2022, 4:51 PM
targets in an image, the docker-in-docker setup can get messy so I’d probably prefer to run it natively as long as it was possible to do so while still building any linked PEXes inside the image
wide-midnight-7859808/25/2022, 4:52 PM
have the most obvious value, goal-wise, over lints/formatters/introspection tools being inside containers.
bitter-ability-3219008/25/2022, 5:03 PM
maybe as well? Requires compilers for some backends
sparse-lifeguard-9573708/25/2022, 5:04 PM
- makes me lean towards a per-subsystem option instead of a per-goal option in the ideal
witty-crayon-2278608/25/2022, 5:27 PM
fields for tests and packages, respectively).
but it definitely makes sense to think through what it might look like to control the environment of other tools
hundreds-father-40408/25/2022, 6:00 PM
but IMO we’d get most of the value from a single global config to say “execute everything in image X instead of directly on the host”This is specifically what I'm trying to figure out: would it be sufficient to only have a single global toggle that is one environment, or will we need to allow more granularity. That impacts the design I strongly suspect people will want more granularity
proud-dentist-2284408/25/2022, 6:17 PM
or BUILD files is problematic.
hundreds-father-40408/25/2022, 6:20 PM
proud-dentist-2284408/25/2022, 6:23 PM
) similar to
hundreds-father-40408/25/2022, 6:29 PM
field. The "Environment" will have all the relevant config like
and env vars. It will also likely say whether to run on localhost vs remote execution vs Docker image. So, I'm thinking that if you say
, that implies to run in the Docker container
I'm trying to figure this modeling out today. It's tricky...so many use cases, and ideally we don't make Pants harder to use if you don't need this Docker feature
proud-dentist-2284408/25/2022, 6:30 PM
or other virtualization tech to use virtualized arm64 from an x86_64 host.
witty-crayon-2278608/25/2022, 7:03 PM
Oof that’s a good point, Jacob. Stu and I also discussed how some environments are not possible to run from your machine: on macOS, I can run on macOS or Linux via Docker. On Linux, I can’t run on macOS (outside of remote execution)yea: there will almost certainly need to be a mechanism for matching the current host “fuzzily” against the configured Environments: for example, if an Environment doesn’t specify a platform, then it applies to all platforms, etc.
wide-midnight-7859808/25/2022, 7:18 PM
I can imagine something similar (config wise) being used to wire upOh how direly I would like this... My mishmash of qemu scripts building arm OSes and packages is ... There's no emoji to describe my painor other virtualization tech to use virtualized arm64 from an x86_64 host.
proud-dentist-2284408/25/2022, 7:37 PM
and env vars?
witty-crayon-2278608/25/2022, 7:39 PM
, when they mean environment variables, I'm not too worried about confusion.
hundreds-father-40408/25/2022, 9:53 PM
witty-crayon-2278608/25/2022, 9:55 PM
hundreds-father-40408/25/2022, 10:07 PM
is not set, then use a local environment: whichever is compatible
is set, it needs to be a docker environment
The main idea here is that "local" environments let you set platform-specific config, without forcing all targets to say when to use what. Pants can figure it out
if we go with the target approach, we could even have
be distinct targets
witty-crayon-2278608/25/2022, 10:34 PM
proud-dentist-2284408/25/2022, 10:38 PM
hundreds-father-40408/25/2022, 10:51 PM
If you have a
that match yours, we won't use Docker
proud-dentist-2284408/25/2022, 10:51 PM