https://pantsbuild.org/ logo
Join Slack
Powered by
I’m struggling a bit with `extra_env_vars` in the ...
# general
a
I’m struggling a bit with 
extra_env_vars
in the 
python_tests
target. I would like to put an absolute path to a directory inside the chroot in an environment variable. Does anyone have an idea how I can achieve this?
e
Does the env var need to be hardcoded? In other words must it be written down as 
X=Y
in the BUILD or can you just write 
X
and have something higher level outside pants set 
X=Y
in the env you run Pants in?
The `extra_env_vars`supports both modes.
a
I think I would like to have it hard coded
e
No way currently without writing custom rule code.
a
Ok, good to know
e
Hardcoded is pretty tricky too! Do you have an absoliute path you can hard code and check in that works for all devs and CI?
a
no
e
Aha - inside the chroot.
a
yes indeed 🙂
so it would be kind of hard to set that using an outside system right?
e
Yeah, we could support "{chroot}" - we allow for this in rule code actually.
Yeah, you should definitely file a feature request. I haven't looked yet though to see if some similar issue is out there already. Presumably it would look like 
FOO=${CHROOT}/bar
- basically Pants allows you to refer to other environment variables and does the interpolation. The only env vars that are fair game would be the ones Pants exposes, so this would stay self contained. Today Pants does not expose 
CHROOT
, so that would need to be added. This is dangerous though, since that absolute path must not be used to produce a binary - for example, with the CHROOT baked in, but this could be buyer-beware.
a
Why is this dangerous? The binary will not function properly or could it even cause vulnerabilities?
And I will file a feature request. And thanks for answering my question.
e
Dangerous if the binary is used by downstream Pants processes. I'm probaluy thinking ahead too far and too hazily, but Pants uses all env vars, argv and all input files needed to run a process to form a fingerprint of that process for caching. If CHROOT is not a part of the fingerprint, but an output of the process depends on CHROOT, we'll have a bad cache entry. That can lead to mysterious downstream errors using the process output as an input somewhere else.
If CHROOT is part of the fingerprint, the process becomes ~uncacheable since each chroot is a fresh new tmp dir of ~random name.
So @abundant-leather-17386 can you not use a pytest fixture or conftest hook for this? It could look at CWD and then expose an env var?
Generally the more you can make tests self contained the better anyhow, Pants aside.
a
That also might be a good direction to look into. Thanks for the suggestion
5 Views
Open in Slack
PreviousNext
Powered by