https://pantsbuild.org/ logo
Join Slack
Powered by
<@UB2J9BQA0>: i’ve made a batch a batch of Edits t...
# development
w
@hundreds-father-404: i’ve made a batch a batch of Edits to the Environment Redesign doc to bring it up to date with 
main
, but i’ve additionally added Suggestions that primarily deal with needing to mark all targets with environments (rather than only roots): would love feedback tomorrow! thank you.
👍 1
h
looks good. I like the idea of multiple environment fields
I'm unclear how batching works for Python with things like Pylint and MyPy -- do they need to be partitioned? If a user sets environment on a python_source target, does that imply that we should also run Black and Isort with that env? For Python, o transitive deps need to have the same environment?
w
do they need to be partitioned?
yea, definitely. afaict, for python an environment should be treated almost equivalently to a resolve, in the sense that runtime involves feeding all of the files into the interpreter, and so while they might be used in different environments here and there safely, in the end they all need to be able to be consumed in one environment that’s not the case for non-interpreted languages
(so, it’s also the case for shell, now that i think about it: will update.)
h
hmmmm that has some pretty negative ramifications. If you want to run a single test with Docker, now all its transitive deps must be marked to use Docker too. I really wanted to avoid that
note that you're now getting into territory where you may need to 
parametrize()
multiple fields: resolve x environment. That does not work well. And means you can't use defaults anymore
w
that’s one use case for different build vs runtime_environments
….but yea. i suppose that the build environment would still need to be compatible with the runtime environment. hm.
👍 1
i wonder if the answer is actually to skip validation… certainly that is what i had been proposing for compiled languages (or, at the most, eventually validating “compatibility” by some definition)
i’ll think through the ramifications of that.
h
At least for test and package, I don't think it matters what environment the deps are using? This might be like interpreter constraints: when you set the ICs for a single target, it should consider the transitive closure. It's now semantically invalid to say "this target is ==3.7" if its deps are "==2.7" If you say these tests should use Docker, then you are implying all the transitive deps need to be buildable within that env
the only tricky case imo is when 
python_source
is a root
i wonder if the answer is actually to skip validation…
coke i think
w
yea, it’s tricky when 
python_source
is a root, because if we haven’t been validating on an ongoing basis, then you might find a file which proves an incompatibility with some environment. BUT, it would have to be proving it at 
check
/ 
lint
/ etc time rather than at runtime (
run
/ 
test
)
…and that’s harder?
hm. i feel like this is one of those situations where we’re eventually going to need to introduce validation via a deprecation. but i’m not sure that we understand all the use cases well enough to do it quite yet.
h
what does incompatibility look like?
w
a root wants to run on macOS, some dependency is only valid on linux
…and so we fail to consume a lockfile, probably.
h
maybe we don't need to eagerly error for that though - it could be overly strict. whereas 
resolve
is wise to eagerly error because it's so unlikely things will work if we don't
w
possibly. this definitely gets to Andreas’ feedback about rendering the environment that is in use in more places… when something does run/fail, it needs to be obvious where it ran/failed
👍 1
maybe we don’t need to eagerly error for that though - it could be overly strict.
yea, for now. until we understand the safe and unsafe use cases, and can introduce more validation.
Open in Slack
PreviousNext
Powered by