Hi, I'm building a pex with `pants export` and it ...
# general
r
Hi, I'm building a pex with
pants export
and it seems to take a long time without seemingly doing anything. Looking to see how I might be able to speed it up. Logs in thread.
Copy code
17:25:23.74 [INFO] Completed: Scheduling: Find interpreter for constraints: CPython<4,>=3.13
17:25:23.75 [INFO] Completed: Scheduling: Get interpreter version
17:26:39.93 [INFO] Extending leases
17:26:39.99 [INFO] Done extending leases
17:27:59.99 [INFO] Extending leases
17:28:00.06 [INFO] Done extending leases
17:29:07.79 [INFO] Completed: Build pex for resolve `python-default`
17:29:07.79 [INFO] Completed: Scheduling: Build pex for resolve `python-default`
17:29:07.80 [INFO] notify invalidation: cleared 1 and dirtied 6180 nodes for: {"", ".tmpg8TTdr.hardlink_canary"}
17:29:07.80 [INFO] notify invalidation: cleared 0 and dirtied 0 nodes for: {"", ".tmpg8TTdr.hardlink_canary"}
17:29:20.06 [INFO] Extending leases
17:29:20.27 [INFO] Done extending leases
I guess I'd just like to see more about what it's doing in these gaps between log messages and see if maybe I can find how to build the pex faster than ~4 minutes
my run command is
pants --keep-sandboxes=on_failure export --resolve=python-default
it's not a big deal except when i'm trying to debug some failure in it
also, i see that these logs shown above don't come out in my stdout when i run this command from bash
on linux
they do show up in
./.pants.d/workdir/run-tracker/pants_run.../logs
but I would like to see them in my stdout
h
What is this pex for? Wondering why you're using
export
and not
package
r
Good question. It ends up creating a developer virtual environment. The docs seem to sound like
export
is right for that, but I'm no expert
h
Ah yes, that makes sense then
Well, except that IIRC
export
produces a virtualenv, not a pex
You can set
py_resolve_format
to
symlinked_immutable_virtualenv
(see https://www.pantsbuild.org/stable/reference/goals/export#py_resolve_format)
That should speed things up, but you'll get a virtualenv that you must not mutate
So that may not be good for your use case, if you want a developer to work freely in the virtualenv
Apart from that you can run with
--keep-sandboxes=always
which will conserve the sandbox that the exporting process is run in (and print its location to the console). Then you can look at that command (it's in
__run.sh
in the sandbox) and run it outside pants with more fine-grained debugging info
r
thanks for the tips!