stack runghc --no-config and --standalone options

[massysett]

I am using stack as a script interpreter to run a script that generates the .cabal file. Problem is, if there is no .cabal file or if the .cabal file is empty (as it will be if a script truncates it before writing the output) stack will complain.

Currently I move the stack.yaml out of the way and then run the script, then move stack.yaml back; I have also kept the script in a separate directory to avoid this problem, but both seem to be yucky solutions. I don't understand why a stack.yaml influences the script interpreter behavior, especially when the script interpreter feature works fine with no stack.yaml at all.

[borsboom]

When you run a script, it runs within the context of the current project.
If you're outside of an explicit project, Stack uses the implicit global
project in ~/.stack/global-project. So there is always a stack.yaml
(since without it Stack has no way to know which resolver to use). I think
in most cases running a script in the context of the current project is the
right default behaviour, but maybe an option to force Stack to use the
implicit global project could come in handy for cases like this.

A workaround for now might be to pass the --stack-yaml argument in the
-- stack line to point it at a different project config file which
doesn't include any packages.

[borsboom]

Huh, Github cut off a part of the comment I posted by e-mail. Here's the rest:

A workaround for now might be to pass the --stack-yaml argument in the
-- stack line to point it at a different project config file which
doesn't include any packages.

[mgsloan]

How about a switch that specifies to not load a stack.yaml, requiring that everything get passed in via CLI - something like --no-config. This way you can't accidentally depend on your global config for your standalone script.

It'd also be good to have a flag for #1208 , like maybe --explicit-packages.

Then, for ease of use, we might have a flag --script that's a synonym for --no-config --install-ghc --explicit-packages.

[massysett]

How about a switch that specifies to not load a stack.yaml, requiring that everything get passed in via CLI - something like --no-config.

This would be helpful. Since stack already has the capability to work without a local project, some way to force it to that behavior would be helpful.

[borsboom]

That all sounds pretty good to me.

[borsboom]

Just want to note I have some misgivings about using the name --script, since there are plenty of cases where the current behaviour is fine, even preferred, for scripts. Perhaps something like --standalone-script to make it more clear?

[mgsloan]

Sure, --standalone-script is a reasonable name. --standalone-defaults could also be a good name, to suggest that it's a bit of a grab bag of flags that make sense for standalone scripts.

[borsboom]

Just --standalone would convey the meaning, so let's go for that!

[mgsloan]

Sounds good to me!

[kadoban]

Shouldn't --standalone be the default, when run as a script interpreter? I'd think in the case of running as a script interpreter, it'd be odd for it to have different basic behavior depending on what directory it's running in, or what files are in the directory.

[mgsloan]

Good point! I'd certainly be fine if running as a script interpreter implied a different set of defaults. This would mean that current stack scripts may get broken, but that may well be worth it.

[sjakobi]

Potentially the -hide-all-packages ghc flag could be useful here?!

[rrnewton]

+1 on standalone being default. But I don't really care one way or the other as long as we have the ability to enable --standalone.

[kadoban]

Seems like this is obsolete/fixed now that the new script command exists.