Don't leave build stuff in my home dir, please
magthe opened this issue · comments
Please consider adding something along the lines of this to the Go PKGBUILDs:
diff --git a/terragrunt/PKGBUILD b/terragrunt/PKGBUILD
index a859eef..44d719a 100644
--- a/terragrunt/PKGBUILD
+++ b/terragrunt/PKGBUILD
@@ -20,6 +20,8 @@ sha256sums=('83b5795b8567449046bd1d9d69e4a43ea0e985762fc6198e469744eb6f29adda')
build() {
cd "${srcdir}/${pkgname}-${pkgver}"
+ export GOPATH="${srcdir}/go"
+
go build \
-ldflags "-X github.com/gruntwork-io/terragrunt.VERSION=${pkgver}" \
-o "${pkgname}-${pkgver}" \
@@ -36,6 +38,8 @@ package() {
install -D -m 0755 \
"${srcdir}/${pkgname}-${pkgver}/${pkgname}-${pkgver}" \
"${pkgdir}/usr/bin/${pkgname}"
+
+ go clean -r -cache -testcache -modcache
}
# vim:set ts=2 sw=2 et:
In order to
- not leave a
~/go/
folder around after build, and - allow AUR helpers like
yay
to clean up automatically after building.
To wit, there is no expectation that running makepkg
has no side effects. The typical way to ensure a build is "sandboxed" is to build in a chroot; this is made possible by using systemd-nspawn
via makechrootpkg
(or if you use a sane helper like aurutils
)
That said, I understand the desire to have builds "sandboxed" and would prefer this myself (although I typically use -bin
packages which avoids this altogether), and can agree that this could be useful behavior for some folks. Thanks for the suggestion!
@magthe I've added a patch setting GOPATH
to $srcdir/.go
. This accomplishes the desired outcome, which is to not have files left over in your user's $GOPATH
(by default, ~/go
) when invoking makepkg
directly or using aur helpers like yay
.
I did not add the go clean
command you suggested as I firmly believe it is the responsibility of the user (if using makepkg
) or tool (e.g. yay
) to clean up after builds, if that's the desired behavior. With makepkg
, you can do this by using the --clean
or --cleanbuild
options. From man makepkg
:
OPTIONS
-c, --clean
Clean up leftover work files and directories after a successful build.
-C, --cleanbuild
Remove the $srcdir before building the package.
Another suggestion is to poke your AUR tool author(s) to build packages in a sandbox (using makechrootpkg
, systemd-nspawn
, or whatever they'd prefer), and clean up that sandbox after building the package. Far too many AUR helpers fail to implement this sort of behavior, which leads to weird issues for users. The poor architecture of many AUR helpers is exactly why they are not recommended for use.
One tool I use is aurutils
, which simplifies the management of a Pacman-compatible repository. I use aurutils
both manually and in an automated manner on a small server I have that builds packages for me on a schedule. From my workstation, I simply add the repository and install/remove/update packages using pacman
.
I should also note that I'm conflicted about this patch. On the one hand, it helps users like yourself who are running makepkg
directly (or using a tool which does) and assuming that it will be sandboxed; on the other, it prevents sharing cached objects across multiple invocations of go build
(and even across package boundaries, libaries, projects), which is actually a benefit if you are running makepkg
directly (or using a tool which does) on built-from-go-source packages, or writing Go packages or binaries in some other capacity on your system.
I offer no guarantees that this patch will live in the codebase forever.
I did not add the go clean command you suggested as I firmly believe it is the responsibility of the user (if using makepkg) or tool (e.g. yay) to clean up after builds, if that's the desired behavior. With makepkg, you can do this by using the --clean or --cleanbuild options.
I'm guessing you didn't try this out. Since the creators of Go decided to give all dependencies 444
as permission they've made makepkg --clean
end with many, many lines like this
rm: cannot remove '<build location>/terragrunt/src/.go/pkg/mod/go.mozilla.org/sops/v3@v3.5.0/LICENSE': Permission denied
and a bunch of leftover files and directories are left in place.
I offer no guarantees that this patch will live in the codebase forever.
That is of course entirely up to you. I'm grateful you made this change at least.
I'm guessing you didn't try this out. Since the creators of Go decided to give all dependencies 444 as permission they've made makepkg --clean end with many, many lines like this
rm: cannot remove '<build location>/terragrunt/src/.go/pkg/mod/go.mozilla.org/sops/v3@v3.5.0/LICENSE': Permission denied
and a bunch of leftover files and directories are left in place.
You're correct, I only tested rebuilding with --cleanbuild
, which doesn't have this same problem.
Hm.
I suppose I can add the go clean
call, as modules would really only be re-fetched if the user A) has deleted the package file, or B) is passing -f
to makepkg
, in which case the argument could be made that re-fetching the modules is fine.
--
I'd stress, again, that this is abnormal and out-of-band for a PKGBUILD
-- it's the responsibility of the user to build the package in a container if that's the behavior they want. This is why makechrootpkg
, makepkg --clean
, and makepkg --cleanbuild
exist (I can recognize that --clean
doesn't work in the case of Go modules).
Since you're using yay
, it's the responsibility of that tool to provide this behavior. A quick search shows Jguer/yay#1213, which I'd recommend you throw your vote behind, so you can yay --chroot
to your heart's content (or whatever the flag ends up being).
Or look into aurutils
and manage AUR packages in a different, perhaps better way.
@magthe More to the point, can I ask why you want to avoid using your user's $GOPATH
when building AUR packages? In theory, it is only beneficial to you, as your builds of this package (and other packages which build Go binaries) may benefit from any modules which you already have cached.
The only concern I can see is related to disk space usage. Am I missing something else?
- I don't program in Go at all, so I don't have
$GOPATH
set, and it pollutes my$HOME
by default. - I have a few other tools written in Go built and installed from AUR and they don't leave intermediate build artefacts outside of the buid folder, so the behaviour of your package surprised me.
- I really think that all packages on AUR should build properly with
makepkg
.
I don't program in Go at all, so I don't have $GOPATH set, and it pollutes my $HOME by default.
That makes sense, as $GOPATH
defaults to $HOME/go
(annoyingly, the module cache should IMO be placed in $HOME/.cache/go
but I digress)
I have a few other tools written in Go built and installed from AUR and they don't leave intermediate build artefacts outside of the buid folder, so the behaviour of your package surprised me.
Can you provide an example of a few of these packages? Are they by reputable maintainers? I would guess that they are running go clean
after building, in the package()
function or a post-installation script. This has the downside that I want to avoid of preventing re-using the module cache between builds which are not cleaned.
I really think that all packages on AUR should build properly with makepkg.
This package does, and has always, built properly with makepkg
. The new behavior of printing warnings out when using the --clean
flag is caused by the movement of the $GOPATH
to a path within $srcdir
, which was done to address the concern you brought up in your first issue comment. The initial issue you posted about did not and does not prevent this package from building successfully (in fact, it re-used the module cache when possible, which was the intended behavior).
@magthe I believe I've found a nice middle ground for the two goals:
- Allow deletion of the module cache so commands like
makepkg --clean
and other processes (e.g.rm -rf
,git clean -fdx
, etc) can delete the workspace as expected - Allow rebuilds not cleaning the workspace to benefit from re-using the module cache
Check out 660e77e for more information.
Nice!