Anyone got a nudge. I'm extracting and archive wit...
# plugins
b
Anyone got a nudge. I'm extracting and archive with an absolute symlink:
Error expanding output globs: Failed to read link ... Absolute symlink
(FWIW I'm invoking the
Process
myself and not using the
ExtractedArchive
rule). Any way to tell pants to ignore absolute symlinks? Or should I hand-pick
output_directories
?
1
--exclude
to
tar
. This should probably be upstreamed along with: • adding
lz4
support (or really any
-I
option) • adding the ability to choose extraction method for arbitrary extensions
w
hm… process output capture should be symlink oblivious
b
Here's the message:
Copy code
Error expanding output globs: Failed to read link "/tmp/process-executionhxcvDG/__extract_archive_dir/somedir/tools/python/python": Absolute symlink: "/usr/bin/python2.7"
w
yea… sec.
b
FWIW I don't need the symlink so
--exclude python
worked linke a charm in unblocking. 🙈
w
this is also sortof a performance issue though if we’re actually expanding them. lemme see.
mm… yea, small bug.
b
🤏🐛
w
hm. so i’ve implemented this, but before i add tests, @fast-nail-55400: what are your thoughts on the probability of us ever wanting to add symlink support to Pants’ use of REAPI?
b
What's the new behavior of symlinks in this scenario
w
they would be captured as files
b
But when materialized they are still symlinks? 🤔
w
no: they are files.
oh, wait, sorry.
you mean what would the new behavior be if we implemented REAPI’s support for symlinks?
with REAPI symlinks, we would capture as a symlink and restore as a symlink, yea.
b
No sorry, I meant new behavior locally.
I assume then the previously symlink is now just a copy of the thing it links to?
w
they would be captured as files
both the new and old behavior is that symlinks are captured as files. but the old behavior is that they cannot escape the sandbox. the new behavior would mean that we would just not ever check whether something was a symlink
b
Ah I see
Better than exclusion args to tar! 🙏
w
we’d always
stat
(in this codepath) rather than `lstat`ing, so we’d never observe the symlink.
f
Symlinks are separate entity in REAPI from files and directories.
So if we support them in REAPI then we capture them as symlinks.
w
@fast-nail-55400: added a comment here: https://github.com/pantsbuild/pants/pull/15211