https://pantsbuild.org/ logo
Join Slack
Powered by
Oh, and another thing that I wish I didn’t have to...
# plugins
b
Oh, and another thing that I wish I didn’t have to ask for: It’d be nice if I could tell a Process that something needed to be run with 
sudo
. 
rpm-ostree
does a bunch of mucking about that needs privileges so, in its current form, it basically refuses to run except as root.
f
I'm not sure just raw "running with sudo" fits into Pants' conception of how builds are supposed to work, since sudo can mess with the environment in ways Pants can't really predict or control, which would make build steps with it less deterministic than they ought to be
I'm dealing with 
rpm
stuff in my project and my current idea about this is to find a way to run build steps in containers. I haven't gotten there yet, so I don't know what challenges will await, but I'd be willing to collaborate if containerized build steps would work for 
rpm-ostree
c
Not sure if it will help you two, but the way I'm building rpms is I have a shell script with 
rpmbuild
and some other prep commands, and that shell script is registered to a experimental_shell_command target. The RPMS directory is set as an output on that target. To make this target run during a 
packaging
goal I have it as the input to a archive target
a proper rpm plugin would make life easy, but i've found this pattern of do-something-via-script, and zip the result is quite powerful
f
the problem is installing build deps... which are other rpms, which require sudo to install... so the only way I see this working is if Pants can run a build step in some container or container-like thing; docker is probably the obvious solution, but I've been playing around with doing it rootless with podman/buildah, or even using dedicated tools like mock
Running 
rpmbuild
with the shell command target makes sense, but you'd have to manage the depedency chain outside of Pants, and there's no guarantees of determinism, especially since your build deps could be changed every time you run dnf/yum upgrades. Pants tries hard to make build steps completely dependent on the inputs it can know about, in essence transforming a build step into a pure function. But there's nothing really stopping code from reaching out to OS-level things; Pants calls the directory it builds things in a "chroot" but it's not really. Code links against system libs, and you could hard-code paths to files outside the execution dir if you wanted. For me using containers is the solution for things like this, but there's a lot of details to get right.
c
I see your point. My rpm builds are quite simple copy artefacts and set permissions, so my only additional dependency is 
rpmbuild
and some core utils like xargs which is simple enough to manage. If you are doing compilation and more complex operations in your .spec I can see why dependency management is so important for you. Builds inside containers would solve this quite well. I imagine other people benefiting from this too as a generic wrapper for other types of builds that Pants doesn't have direct support. Not sure if it will help you but @fresh-cat-90827 has been chipping away at debian packaging support. https://github.com/pantsbuild/pants/issues/12421
f
and the Pants team is working hard on https://github.com/pantsbuild/pants/issues/13682 as well. Hopefully these kinds of things will make interacting with os-level packaging much easier
c
That's awesome! Thanks for sharing
f
Excellent discussion, thanks folks for spending time sharing your approaches to RPM packaging. I wish I had more time to dedicate towards Debian packaging, it was on hold for a while for me, I am afraid
f
I think run-in-container support is going to be the thing that helps with this for every ecosystem, as well as probably unlocking more tools for native code (I think cross-platform support is the main reason the Toolchain folks are focused on this right now, but it's clearly useful for other things)
👍 2
3 Views
Open in Slack
PreviousNext
Powered by