Extra blank lines introduced with `config set`

[philderbeast]

Follow up on #5813. With the current ./stack.yaml in this project that has a multiple line string with blank lines, I'm seeing extra blank lines introduced. Please don't do that.

> cat stack.yaml
# GHC 9.2.4
resolver: nightly-2022-09-05

packages:
- .

drop-packages:
# See https://github.com/commercialhaskell/stack/pull/4712
- cabal-install

docker:
  enable: false
  repo: psibi/alpine-haskell-stack:9.2.4

nix:
  # --nix on the command-line to enable.
  packages:
  - zlib
  - unzip

flags:
  stack:
    developer-mode: true

ghc-options:
  "$locals": -fhide-source-paths

user-message: |
  If building Stack on macOS, you are advised to use stack-macos.yaml as the
  project-level configuration file, and command:

  stack --stack-yaml stack-macos.yaml build

  See that configuration file for further information.

cabal run stack -- config set install-ghc true

git diff
diff --git a/stack.yaml b/stack.yaml
index 13b905c2..51e2782e 100644
--- a/stack.yaml
+++ b/stack.yaml
@@ -23,12 +23,15 @@ flags:
     developer-mode: true

 ghc-options:
-  "$locals": -fhide-source-paths
+  $locals: -fhide-source-paths

 user-message: |
   If building Stack on macOS, you are advised to use stack-macos.yaml as the
   project-level configuration file, and command:

+
+
   stack --stack-yaml stack-macos.yaml build

   See that configuration file for further information.
+install-ghc: true

[mpilgrem]

Is this problem something introduced with #5813?

It does not seem to happen with the original Stack 2.7.5. That is based on this experiment:

stack.yaml file before:

resolver: lts-19.22

packages:
- .

user-message: |
  This is line one.

  This is line two.

stack.yaml file after stack config set install-ghc true:

user-message: |
  This is line one.

  This is line two.
packages:
- .
install-ghc: true
resolver: lts-19.22

re-ordered ... but no blank lines inserted in the user message.

[mpilgrem]

Based on some experiements, the bug seems to be this: for every blank line in the user-message: another blank line is added after the first line in the user message. EDIT: Actually, it is a little more complex than that:

resolver: lts-19.22
packages:
- .
user-message: |

  This is line one.

  This is line two.

  This is line three.

becomes:

resolver: lts-19.22
packages:
- .
user-message: |2



  This is line one.


  This is line two.

  This is line three.
install-ghc: true

with a 2 added after user-message: | (that is a block scalar indentation indicator).

[philderbeast]

Is this problem something introduced with #5813?

Yes I believe so.

[mpilgrem]

Is it difficult to fix? It would be nice to release Stack 2.9.1 with this fixed. However, it is also a 'small' bug. I think the number of people using stack config set on a stack.yaml containing a user-message: is likely to be very small indeed.

[mpilgrem]

In the light of the above, I did wonder about the existing algorithm more generally. It seems rather complicated. Does it need to be so complicated?

Is the problem to be solved essentially this (using the install-ghc: key as an example)?

• look through a YAML file for a line with the format: install-ghc:<1 or more spaces><old_value><optional YAML comment>.
• If the line is encountered, then - if <new_value> differs from <old_value>, then replace that line only with: install-ghc:<same no of spaces><new_value><same optional YAML comment>. (If the line is already duplicated, let that be the user's problem.)
• If the line is not encountered, add install-ghc: <new_value> to the last line of the file.

Or am I missing something that drives the complexity?

[mpilgrem]

Or alternatively:

• parse the YAML file
• if the parsed file contains the key and <old_value>=<new_value> do nothing
• if the parsed file does not contain the key, then add key: <new_value> to the end of the YAML file
• otherwise, look in the YAML file for the line that needs to be replaced (we know it exists), and replace it.

[philderbeast]

Since multiline string values include their blank lines, skipping those for reinsertion fixed the problem.