https://pantsbuild.org/ logo
Join Slack
Powered by
So I run my builds on MacOS. I noticed that both f...
# general
g
So I run my builds on MacOS. I noticed that both for 
repl
and 
run
current working directory is NOT set to a sandbox dir, even though they are created. Looks like a bug to me.
h
This is deliberate.
The thinking is that the sandbox is not a useful cwd for a user-facing process, but the workspace is
Pants’s internal processes, like a linter or test, invoked to produce some result, run with the cwd set to the sandbox, but a user-triggered process (like 
run
or 
repl
) would not know what to do with a sandbox, since it has no knowledge of it or ability to affect its creation
The main issue with this, and maybe this is what you’re encountering, is that if your process tries to access its own code or resources via the cwd, then that will fail
Which is why well-behaved processes load resources via the classloading mechanism
g
@happy-kitchen-89482 How would you access a file downloaded via http_source then from inside a Python module 
file(source=http_source
? Can't export the downloaded file and there are no env vars pointing to 
chroot
in neither 
repl
nor 
run
. Only reliable way I found to hack it is to use preview-environments with 
shell-command
. I can't use 
resource
, because the files are multi-GBs and I don't want to make container images large.
h
Referring back to the other thread, looks like you found a reasonable solution. I think the issue is that your python code wants to load the file relative to the cwd? But the safe way to do stuff like this is to load via something like 
importlib.resources
, that locates data on the PYTHONPATH.
But that is the 
resource
target, which you don’t want to use because you don’t want the file to be embedded in an image
So some hackery is required, as “materialize source files into the workspace” isn’t a use-case we designed for. Still, glad you got something working!
🙂 1
6 Views
Open in Slack
PreviousNext
Powered by