haskell-stack 1.0: set stack root to home directory

[Ionic (Mihai Moldovan)]

Stack root is currently defined as ${workpath}/.stack.

That's... okay, but leads to a weird issue (probably due to a bug in stack itself): during the destroot phase, it ignores this environment variable, uses ~/.stack instead, re-downloads GHC, populates that directory and, worst of all, rebuilds all the packages.

This rebuild is not just wasteful, but actually triggers a second bug in stack: it doesn't pass down GHC options (which I need for legacy-support integration) during stack install/stack build --copy-bins. So the rebuild will fail and I have no idea how to fix stack to pass down the given GHC options.

Now, this said, we can easily fix that by defining the stack root relative to the home directory. This sounds a bit dangerous, but shouldn't be, since we set $HOME to ${workpath}/.home.

I could have committed this myself, but I'm looking for comments.

Case in point: if I set haskell_stack.stack_root "${workpath}/.home/.stack, the second rebuild in the destroot phase vanishes completely.

[neverpanic (Clemens Lang)]

Sounds reasonable to me. I'm surprised to find stack use ~/.stack, though, since we're running things as macports user, so it should be using ~macports/.stack, where it cannot write. I'm guessing that happens because destroot runs as root.

[kencu (Ken)]

you know stack is set up to purposefully not use any system installed ghc unless specifically instructed to do so, and will always download the ghc that the software it is trying to build that says it needs. and also all new packages every time, just the same.

This is a purposeful stack feature, and can be overridden with Yet Another stack option, " use system ghc", but as ghc is touchy, it is by no means certain that the system ghc will build the software.

I have a patched ghc working perfectly all the way back to 10.6, but you can't easily make stack USE a custom ghc, you have to override it's packaging system settings, and that is Not Easy.

[kencu (Ken)]

for these stack ports, the idea was to leave nothing behind, so everything stack installs is meant to disappear at the end of the build.

I thought it was using macports home dir for the stack stuff, and blowing that away after the build was done.

Fairly sure that's what it does on my systems.

[kencu (Ken)]

because stack will not access a patched ghc, I was wondering if I might get Ben upstream to accept patches into trunk.... but they are twisting like crazy right now with a barely functional ecosystem for arm64.

[kencu (Ken)]

my plan currently is to just make a binary of pandoc and a few other things for older systems manually and install that, and leave ghc/stack/cabal/the rest alone on older systems for the general case.

[kencu (Ken)]

here are ghc, stack, and cabal for all darwin systems back to 10.6.8:

<​https://github.com/kencu/ghc-for-older-darwin-systems/releases>

[ryandesign (Ryan Carsten Schmidt)]

Ken, did you read the ticket? Mihai says the port downloads and builds stuff in the build phase, then downloads and builds stuff again in the destroot phase. That's surely undesirable and what he's proposing be fixed.

Clemens, when Mihai says it uses ~/.stack, I presume he means that ~ expands to the value of the HOME environment variable, which MacPorts sets to ${workpath}/.home. As you say, MacPorts cannot write to the user's real home directory nor to the macports user's home directory /opt/local/var/macports/home, so if it were trying to use either of those the build would not succeed, but apparently it does succeed so it must not be doing that.

[Ionic (Mihai Moldovan)]

Replying to neverpanic:

Sounds reasonable to me.

I still cannot quite explain what is happening there, though. I've been trying to reproduce this with a minimal test case to report this as a bug to upstream, but so far haven't finished/managed.

It's almost certainly a combination of using a build user and then running destroot as root. The weird part is that we are supplying --allow-different-user, which should enable sharing. ${workpath}/.stack is created as the macports user, so it does (initially) have write permissions there.

The weirdest part is that it's ignoring STACK_ROOT=${workpath}/.stack when running as root in the destroot phase (and falling back to ${HOME}/.stack, a.k.a. ${workpath}/.home/.stack instead), which... just doesn't make sense to me.

You've put me on the right track, though, I think, since most files in ${workpath}/.stack seem to be owned by root instead of macports. They also are newer than the ones in ${workpath}/.home/.stack, which are owned by macports only, so maybe I just confused the two directories.

I'm surprised to find stack use ~/.stack, though, since we're running things as macports user, so it should be using ~macports/.stack, where it cannot write. I'm guessing that happens because destroot runs as root.

I didn't really mean ~loggedinuser/.stack, but ${HOME}/.stack, which is ${workpath}/.home/.stack for both the macports build user and root in the destroot phase, since we set HOME explicitly to ${workpath}/.home for builds. The PG is not touching anything outside of its workpath, luckily. It would be totally unacceptable if it did.

[neverpanic (Clemens Lang)]

Yeah, in that case I think using ${workpath}/.home/.stack sounds like a good solution. If that fixes the problem for you, sounds fine to commit this.

[essandess (Steve Smith)]

Please see ​https://github.com/macports/macports-ports/pull/10086

Thank you very much for posting this issue @Ionic.

Would you please sanity check the implementation?

[kencu (Ken)]

Replying to ryandesign:

Ken, did you read the ticket? Mihai says the port downloads and builds stuff in the build phase, then downloads and builds stuff again in the destroot phase. That's surely undesirable and what he's proposing be fixed.

I read it.

I have never seen that behavior happen. I don't see it now when I build pandoc. I don't see any logs in this ticket showing that happening. People can be mistaken. Perhaps I am mistaken, and it really is happening, and I just don't see it.

[kencu (Ken)]

log of pandoc build, destroot on Catalina

[essandess (Steve Smith)]

In 228dad0f175782a7d6862fdeccd2b03c60cdb755/macports-ports (master):

haskell_stack: Bugfix of stack_root

Fixes: #62228