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