stack-2.9 for LTS-21

[juhp]

I would really like to see stack-2.9 in current Stackage Nightly (ie for coming lts-21).
We have stack-2.9.1 in lts-20, but newer persistent and unix-compat versions in current nightly
prevent stack-2.9.3 from building in nightly.

I think the changes (backport) needed is rather small:

diff --git a/package.yaml b/package.yaml
index 5ef569c37..d698b5b27 100644
--- a/package.yaml
+++ b/package.yaml
@@ -102,7 +102,7 @@ dependencies:
 # In order for Cabal (the tool) to build Stack, it needs to be told of the
 # upper bound on persistent. See
 # https://github.com/commercialhaskell/stack/pull/5677#issuecomment-1193318542
-- persistent >= 2.13.3.5 && < 2.14
+- persistent >= 2.13.3.5 && < 2.15
 - persistent-sqlite
 - persistent-template
 - pretty
diff --git a/src/Stack/Config.hs b/src/Stack/Config.hs
index 11795d56b..cde3b7989 100644
--- a/src/Stack/Config.hs
+++ b/src/Stack/Config.hs
@@ -7,6 +7,7 @@
 {-# LANGUAGE RecordWildCards     #-}
 {-# LANGUAGE ScopedTypeVariables #-}
 {-# LANGUAGE TypeFamilies        #-}
+{-# LANGUAGE CPP                 #-}
 
 -- | The general Stack configuration that starts everything off. This should
 -- be smart to fallback if there is no stack.yaml, instead relying on
@@ -89,7 +90,11 @@ import           System.Console.ANSI
 import           System.Environment
 import           System.Info.ShortPathName ( getShortPathName )
 import           System.PosixCompat.Files ( fileOwner, getFileStatus )
+#if MIN_VERSION_unix(0,7,0)
+import           System.Posix.User ( getEffectiveUserID )
+#else
 import           System.PosixCompat.User ( getEffectiveUserID )
+#endif
 
 -- | If deprecated path exists, use it and print a warning.
 -- Otherwise, return the new path.
diff --git a/src/Stack/Docker.hs b/src/Stack/Docker.hs
index 6c2888a81..8fbc1c0c3 100644
--- a/src/Stack/Docker.hs
+++ b/src/Stack/Docker.hs
@@ -7,6 +7,7 @@
 {-# LANGUAGE RankNTypes          #-}
 {-# LANGUAGE RecordWildCards     #-}
 {-# LANGUAGE ScopedTypeVariables #-}
+{-# LANGUAGE CPP                 #-}
 
 -- | Run commands in Docker containers
 module Stack.Docker
@@ -66,7 +67,11 @@ import           System.IO.Unsafe ( unsafePerformIO )
 import           System.Posix.Signals
 import qualified System.Posix.User as PosixUser
 #endif
+#if MIN_VERSION_unix(0,7,0)
+import           System.Posix.User as User
+#else
 import qualified System.PosixCompat.User as User
+#endif
 import qualified System.PosixCompat.Files as Files
 import           System.Terminal ( hIsTerminalDeviceOrMinTTY )
 import           Text.ParserCombinators.ReadP ( readP_to_S )
diff --git a/src/Stack/Storage/Util.hs b/src/Stack/Storage/Util.hs
index 058f5fef3..d2741833c 100644
--- a/src/Stack/Storage/Util.hs
+++ b/src/Stack/Storage/Util.hs
@@ -4,6 +4,7 @@
 {-# LANGUAGE MultiParamTypeClasses #-}
 {-# LANGUAGE TypeFamilies          #-}
 {-# LANGUAGE TypeOperators         #-}
+{-# LANGUAGE CPP                   #-}
 
 -- | Utils for the other Stack.Storage modules
 module Stack.Storage.Util
@@ -26,6 +27,9 @@ updateSet ::
        , PersistEntity record
        , MonadIO m
        , PersistQueryWrite backend
+#if MIN_VERSION_persistent(2,14,0)
+       , SafeToInsert record
+#endif
        )
     => (parentid -> value -> record)
     -> EntityField record parentid
@@ -51,6 +55,9 @@ updateList ::
        , PersistEntity record
        , MonadIO m
        , PersistQueryWrite backend
+#if MIN_VERSION_persistent(2,14,0)
+       , SafeToInsert record
+#endif
        )
     => (parentid -> Int -> value -> record)
     -> EntityField record parentid
diff --git a/stack.cabal b/stack.cabal
index a3e884227..a68f3cd2b 100644
--- a/stack.cabal
+++ b/stack.cabal
@@ -1,6 +1,6 @@
 cabal-version: 2.0
 
--- This file has been generated from package.yaml by hpack version 0.35.1.
+-- This file has been generated from package.yaml by hpack version 0.35.2.
 --
 -- see: https://github.com/sol/hpack
 
@@ -316,7 +316,7 @@ library
     , pantry >=0.8.1
     , path
     , path-io
-    , persistent >=2.13.3.5 && <2.14
+    , persistent >=2.13.3.5 && <2.15
     , persistent-sqlite
     , persistent-template
     , pretty
@@ -440,7 +440,7 @@ executable stack
     , pantry >=0.8.1
     , path
     , path-io
-    , persistent >=2.13.3.5 && <2.14
+    , persistent >=2.13.3.5 && <2.15
     , persistent-sqlite
     , persistent-template
     , pretty
@@ -565,7 +565,7 @@ executable stack-integration-test
     , pantry >=0.8.1
     , path
     , path-io
-    , persistent >=2.13.3.5 && <2.14
+    , persistent >=2.13.3.5 && <2.15
     , persistent-sqlite
     , persistent-template
     , pretty
@@ -695,7 +695,7 @@ test-suite stack-test
     , pantry >=0.8.1
     , path
     , path-io
-    , persistent >=2.13.3.5 && <2.14
+    , persistent >=2.13.3.5 && <2.15
     , persistent-sqlite
     , persistent-template
     , pretty

Would you consider doing a (edit) 2.9 point release for this, please?
I think it would need a 2.9 branch.

Also it would be great to coordinate better with having stack in Stackage more consistently going forward. :-)

[mpilgrem]

Is stack (the library) suitable for a Stackage snapshot? The library only exists to support Stack (the executable) and only aims to build with the set of dependencies specified in the stack.yaml which is included as an extra-source-files in stack.cabal. If it builds with other versions of dependencies, that is by luck rather than by design. As explained in the stack.cabal description and on Hackage, the library is only published there to allow 'bootstrapping' (that is, in some circumstances. Stack will use the Hackage package to build itself via stack upgrade) and for 'convenience' (that may refer to the convenience of having its Haddock documentation online).

I think the unix-compat < 0.7 is needed because unix-compat-0.7 dropped System.PosixCompat.User used by stack-2.9.3.

In the history of the project, I don't think there has been a published version of the library that did not correspond to a published 'official' Stack executable, so I hestitate before publishing a stack-2.9.5 for which there is no Stack 2.9.5 - the version of Stack that followed 2.9.3 being the current 2.11.1.

I could move the next version of Stack on to GHC 9.4.5 - I had been waiting for a Stackage LTS before doing so, but preparing with the stack-ghc-9.4.5.yaml. The rate limiting step is @psibi creating a GHC 9.4.5 Alpine docker image to replace repo: fpco/alpine-haskell-stack:9.2.7. I'd like to get the next version of Stack out quite soon, as I have discovered a packaging problem with the Windows Stack installer (now fixed) that affects users with user PATH environment variables that breach a 1024 character limit.

[juhp]

Sorry this isn't really about the stack library - I think it is good to have stack buildable from stackage always.

I wanted to correct/tweak my suggestion: I think a point release like 2.9.3.1 would be just fine.
(I didn't say explicitly but I believe the above patch works correctly: I added CPP for unix-compat.)

And for a bit more general context: I consider Stackage also a Haskell distribution of packages (of course the primary consumer is stack, but for example Fedora Haskell packages are also based on Stackage LTS versions, though they are not built with stack).

[mpilgrem]

By 'buildable from Stackage', do you mean avoiding extra deps? I do try to avoid extra-deps in Stack's stack.yaml, but sometimes they are unavoidable: as a Stackage snapshot is a set of packages that work well together on Linux, Stack 'runs ahead' to include fixes relevant to other operating systems that have not yet arrived in a Stackage snapshot. So 'no extra deps' can't be a 'point of principle'.

As for ansi-terminal-1.0, which I maintain, I am not sure why Stackage is currently 'stuck' on 0.11.5, as it only a matter of relaxing upper bounds for the dependencies and I raised pull requests for all the packages affected. I was hoping that would get 'freed up' before the next version of Stack was released.

[mpilgrem]

@juhp, I've created a branch stack-2.9.3.1 on the repository that should be at the point that the v2.9.3 tag was created. If you raise a pull request targetting that branch, I'll then arrange a Hackage-only release of stack-2.9.3.1. I see now that there have been 'Hackage-only' releases in the past (1.6.1.1, 1.6.3.1, 1.9.1.1, 1.9.3.1, 2.1.1.1, 2.1.3.1, 2.5.1.1).

[mpilgrem]

stack-2.9.3.1 uploaded to Hackage.