Don't repeat suggestion when no project config

[philderbeast]

Follow up on #6601, improving the error message for #6600. In the case of a script when there is no project-level config, don't make suggestions to change the project-level config.

Here's a concrete example of before and after:

Error: [S-4804]
       Stack failed to construct a build plan.
       
       While constructing the build plan, Stack encountered the following errors. The 'Stack
       configuration' refers to the set of package versions specified by the snapshot (after any
       dropped packages, or pruned GHC boot packages; if a boot package is replaced, Stack prunes
       all other such packages that depend on it) and any extra-deps:
       
       In the dependencies for dhall-1.42.1:
         * Diff must match >=0.2 && <0.5, but Diff-0.5 is in the Stack configuration (latest
           matching version is 0.4.1).
         * ansi-terminal must match >=0.6.3.1 && <1.1, but ansi-terminal-1.1.1 is in the Stack
           configuration (latest matching version is 1.0.2).
       The above is/are needed since dhall is a build target.
       
       Some different approaches to resolving some or all of this:
       
         * To ignore all version constraints and build anyway, in
-          /home/<USERNAME>/.stack/config.yaml (global configuration) or
-          /home/<USERNAME>/.stack/config.yaml (project-level configuration), set allow-newer:
-          true.
+          /home/<USERNAME>/.stack/config.yaml (global configuration) set allow-newer: true.
         
         * To ignore certain version constraints and build anyway, also add these package names
           under allow-newer-deps: dhall.
         
-        * Recommended action: try adding the following to your extra-deps in
-          /home/<USERNAME>/.stack/config.yaml (project-level configuration):
-          
-          - Diff-0.4.1@sha256:4f5dddf48a9d4c3d753f02474a409c05fadb10d1fc53e145be45a1dfdb7552e9,1330
-          - ansi-terminal-1.0.2@sha256:1f90bb88e670ce63fbf2c9216d50857f2419582f1c6791e542c3eab97ecfd364,2897

[philderbeast]

@mpilgrem I don't know under what circumstances this might be true when not a script.

[mpilgrem]

@philderbeast, I've worked out that your error message can be generated with Haskell script:

{- stack script
   --snapshot nightly-2024-06-07
   --package dhall
-}

main = pure ()

and I agree that Stack should not:

• be making recommendations about a project-level configuration file when there is none; or
• be making recommandations about adding project-level configuration options to a global configuration file.

I am puzzled why, currently, Stack thinks a global configuration file is a project-level configuration file. I am going to try to understand that first, before looking at your pull request.

[mpilgrem]

The answer to my puzzle is found in Stack.Config.withBuildConfig:

  (project', stackYaml) <- case config.project of
    ...
    PCNoProject extraDeps -> do
      p <- ...
      pure (p, config.userConfigPath) -- <<<< refering to the global configuration file!

Q: Does that make any sense? How is the stackYaml field of a value of type BuildConfig actually used?

[mpilgrem]

I am thinking that rather than:

data BuildConfig = BuildConfig
  { ...
  , stackYaml  :: !(Path Abs File)
    -- ^ Location of the stack.yaml file.
    --
    -- Note: if the STACK_YAML environment variable is used, this may be
    -- different from projectRootL </> "stack.yaml" if a different file
    -- name is used.
  ...
  }

this should be:

data BuildConfig = BuildConfig
  { ...
  , yamlFile :: !Either (Path Abs File) (Path Abs File)
    -- ^ Either (Left) the location of the global configuration file or,
    -- in most cases, (Right) the location of the project-level
    -- configuration file.
    --
    -- Note: if the STACK_YAML environment variable is used, this may be
    -- different from projectRootL </> "stack.yaml" if a different file
    -- name is used.
  ...
  }

[mpilgrem]

@philderbeast, in the end, I decided to address what you had identified at its 'origin' (the type of the field of the BuildConfig constructor) rather than 'at the end' (in the display of the exception). That lead to other refactoring, because the name of the field (and other identifiers) was a bit of a misnomer. That is all in #6607. I've also extended the online help about the contents of the Stack root, in 6d6394e. Once #6607 is merged (I need to do some more testing locally, although I am confident that my changes have not broken anything), I'll close this in favour of it.

[mpilgrem]

Closing, because #6607 has been merged.