Got into a peculiar situation running an operation...
# development
f
Got into a peculiar situation running an operation that uses
chroot
.
Reading the docs:
When Pants runs most processes, it runs in a chroot (temporary directory). Usually, this gets cleaned up after the Process finishes. You can instead run ./pants --no-process-execution-local-cleanup, which will keep around the folder.
The plugin I work on (building a Debian package) is run itself as
chroot
(and Pants runs the
Process
under
chroot
as well). This causes the
dpkg-deb
(system utility that builds a Debian package) to fail reading the input files. By running with
--no-process-execution-local-cleanup
, I can see that the necessary files have been copied and the
__run.sh
contains correct instructions and can be re-run in that temp directory producing the expected results. However, the
./pants package //:sample-debian-package --no-process-execution-local-cleanup
command fails.
Copy code
stdout:
dpkg-deb: building package 'sample-debian-package' in 'sample-debian-package.deb'.

stderr:
dpkg-deb (subprocess): unable to execute tar -cf (tar): No such file or directory
dpkg-deb: error: tar -cf subprocess returned error exit status 2
I don’t think there was a precedent for this — as far as I know, none of the Pants internal operations (or via plugins) deal with
chroot
(in the same way that Debian
dpkg-deb
utility does). I’ve researched on
dpkg-deb
and how one can configure it with regards to
chroot
, but haven’t found anything useful. Is there a way to experiment running a
Process
not under
chroot
to see if it is indeed the cause of the trouble so that we could think of a workaround?
f
does
tar
need to be available in the chroot setup by Pants? and is it?
(My thought is whether
dpkg-deb (subprocess): unable to execute tar -cf (tar): No such file or directory
refers to
tar
being missing.)
f
does tar need to be available in the chroot setup by Pants?
I wish I knew how to check that 🙂
that is,
tar
will be used by
dpkg-deb
to create an archive, but I am not sure if I have to tell Pants explicitly that I want
tar
executable to be available? Isn’t it available if it’s on the
$PATH
?
f
well it can be on the PATH but those directories will be inaccessible from within the chroot
this assumes that a chroot is involved.
so to debug, invoke some commands as part of your invocation of
dpkg-deb
to display $PATH and whatever else you think relevant
h
Look at archive.py, there is a type like Tar or TarBinary iirc that uses BinaryPaths to find the preinstalled Tar program. For dpkg, you'll want to set the Process's
env
so that PATH includes the path to the tar's
first_path
. I'm afk but I think if you grep you'll see how that type gets used
e
To clarify, Pants does not use the
chroot
command. We hijack the term and do something much less stringent.
1
f
@fast-nail-55400 thank you! @hundreds-father-404 I have now:
Copy code
tar_binary_path = await find_tar()
print({"PATH": tar_binary_path.path})
which gives me
Copy code
19:01:01.47 [INFO] stdout: "{'PATH': '/usr/bin/tar'}"
19:01:01.47 [INFO] stdout: "\n"
the problem remains:
Copy code
stderr:
dpkg-deb (subprocess): unable to execute tar -cf (tar): Not a directory
dpkg-deb: error: tar -cf subprocess returned error exit status 2
is passing
env={"PATH": tar_binary_path.path},
to the
Process()
sufficient to expose the executables on the
$PATH
?
oh it works, sorry, of course it has to be
"{'PATH': '/usr/bin'}"
I read that
pathlib
should be avoided, but would using
Path(tar_binary_path.path).<http://parent.as|parent.as>_posix()
be appropriate here?
to get from
'/usr/bin/tar'
to
'/usr/bin'
h
Path
should be avoided, but you can use
str(PurePath(tar_binary_path.path).parent)
safely!
tar_binary_path = await find_tar()
Instead of calling that, put
TarBinary
in the signature for your new
@rule
, which will cause the engine to run the rule
find_tar
. I'm really surprised
await find_tar()
worked!
f
amazing, I’ve got my first Debian package created in the
dist/
😄
🙌 2
🚀 2