https://pantsbuild.org/ logo
Join Slack
Powered by
<@U06A03HV1> &gt;&gt; If one user wants to run tes...
# development
p
@witty-crayon-22786
> If one user wants to run tests locally and another wants to run tests in docker, the design doesn’t account for that yet (afaict).
it allows for a Linux user to skip using Docker to build a target, while a macOS user does use Docker… that’s not quite the same thing, but possibly close enough?
i’m curious about the “individual choice of which environment to run things in” use cases, because the way i’ve been thinking about it is that someone defining the target essentially wants to say: “this needs to run on a Linux with these properties”, rather than that necessarily being a consumer’s choice
Even more narrow than that. Given two users, both on linux: One user wants to run everything via docker as they have a very slim host for the development box, and the other user (typically me) wants everything to run locally (as my development machine has many interpreters and other programs installed globally - so I don’t want the overhead of docker). Is that possible with Environments today?
w
It is possible to globally disable docker or remote execution, yea.
You would need your environments set up a particular way though: 
docker_environment(.., fallback_to="local_linux")
Then if docker was disabled it would run locally
p
ok. Then maybe what I want to do is already possible. I’ll have to play with it.
w
But I have definitely been assuming that the opposite ordering will be more common: local falls back to docker.
Local falls back to docker assumes more "predicates" on the environment though, to confirm that certain things are present
p
That is the order I would prefer, local falls back to docker. Is there a way in that case to have people tell pants to use docker for everything?
w
Um, sort of. But to be clear, this "users needing to override things" aspect is temporary I hope. With good predicates, users mostly shouldn't need to make this choice
p
And then, to throw something else in the works, StackStorm often encourages people to use vagrant for development. So, some users would fall back to using docker while others would fall back to using vagrant. (speaking of which, support for running in vagrant would be fantastic)
So, with the predicates, a rule (or set of rules) would inspect the local platform to see if it is compatible, and then fall back to using docker if not. So, that inspection work would be cached and wouldn’t need to be repeated. Right?
f
maybe some sort of "ssh_environment" (which would work not only for vagrant but any remote development box)?
➕ 1
🤔 1
w
@proud-dentist-22844: correct. The environment name is resolved to an environment once per run
p
OK. That’s more capable than I realized. I’ll have to dive into configuring that for the StackStorm repo. Thanks!
👍 1
That might mean that one of the items I added to the pants survey is not needed… oops 😄
b
No big deal, it just means we get to check off one item as Done almost immediately!
p
lol
b
You made us look extra cleverly responsive!
😆 1
w
relatedly: here is a very high level draft blog post on environments: would love your feedback. https://docs.google.com/document/d/1H1xKE7pYyCQAU762yYI9hPcIFLbXQVYNkxYQPvdOzSU/edit#
🎉 1
p
Nice. That's a good intro. The "Try it out" section needs more details on how. If the docs are the place to learn more, then repeat the link to the docs.
Reading the docs, I'd like less of a reference document and more of a tutorial to help in quickly setting up environments and what questions to ask while doing so. The examples section on the docs has targeted recipe/cookbook still docs. I need more of a quick broad walk through. https://www.pantsbuild.org/docs/environments#example-workflows
What is the relationship between the 
*_environment
target fields (all of 
name
, 
platform
, 
compatible_platforms
) and the 
environment
field of other targets? Looking at this sample in the 2.15 blog , I see environments with 
name="macos"
and 
name="local_busybox"
, and then another target with 
environment=parametrize("linux", "macos")
- is there another environment named “linux”? Or does it look at the platform to know that if something needs 
environment=linux
then it should use the 
docker_environment(name="local_busybox", platform="linux_x86_64")
? I’m really struggling to wrap my mind around environments. It feels like I understand and then I read a bit more and I feel confused again.
🙏 1
f
The environment names are mapped to target addresses in the 
pants.toml
.
p
oh yeah! That would be helpful to show in the example in the blog post (show both pants.toml and the BUILD snippet).
b
This is really good feedback. Thank you, Jacob!
👍 1
2 Views
Open in Slack
PreviousNext
Powered by