Closed philderbeast closed 2 weeks ago
@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:
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.
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?
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.
...
}
@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 6d6394ef123c6b00406a68927bacec9bd5c2fede. 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.
Closing, because #6607 has been merged.
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: