Stack users: a short, or shorter, alternative to `--stack-yaml`?

Links
1

Stack users, I am canvassing for views on introducing a short, or shorter, alternative to command line global flag --stack-yaml. The corresponding repository issue for views is here:

1 Like
2

I think I’m suffering from the same problem. I have a stack.yaml to test with Liquid Haskell:

  # For LiquidHaskell:
  # ghc-9.10.1 should work with the new liquidhaskell-0.9.10.1, this actually works!
  - liquidhaskell-0.9.10.1
  - liquidhaskell-boot-0.9.10.1
  - liquid-fixpoint-0.9.6.3.1
  - smtlib-backends-0.4
  - smtlib-backends-process-0.3
  - ghc-internal-9.1001.0
  # ghc-9.8.4 should work with the new liquidhaskell-0.9.8.1, both 0.9.8.1 and 0.9.8.2 seems broke
  # - liquidhaskell-0.9.8.1
  # - liquidhaskell-boot-0.9.8.1
  # - liquid-fixpoint-0.9.6.3
  # - smtlib-backends-0.4
  # - smtlib-backends-process-0.3
  # ghc-9.6.6 should work with the new liquidhaskell-0.9.6.3.1, this actually works!
  # - liquidhaskell-0.9.6.3.1
  # - liquidhaskell-boot-0.9.6.3
  # - liquid-fixpoint-0.9.6.3
  # - smtlib-backends-0.4
  # - smtlib-backends-process-0.3
  # ghc-9.4.8 should work with the new liquidhaskell-0.9.4.7.0, this actually works!
  # - liquidhaskell-0.9.4.7.0
  # - liquidhaskell-boot-0.9.4.7.0
  # - liquid-fixpoint-0.9.4.7
  # - smtlib-backends-0.4
  # - smtlib-backends-process-0.3
  # ghc-9.2.8 should work with the new liquidhaskell-0.9.2.8.0, this actually works!
  # - liquidhaskell-0.9.2.8.0
  # - liquidhaskell-boot-0.9.2.8.0
  # - liquid-fixpoint-0.9.2.5
  # - rest-rewrite-0.4.4
  # - smtlib-backends-0.4
  # - smtlib-backends-process-0.3

I always thought it would be good to have some way to switch to a specific case of extra-deps based on the ghc version.

Perhaps the more optimal solution would be for the Liquid Haskell folks to add the dependencies to the Stackage LTS.

I also saw the recent yamlscript post and thought that could be applicable as well.

I’m interested in seeing what everyone else thinks.

Thanks,
NW

1 Like
3

I am typically have one stack.yaml file for each GHC (major) version VER, named stack-VER.yaml specifying the snapshot for this GHC version and the respective extra-deps.
Then I invoke stack test –stack-yaml=stack-VER.yaml for each VER I want to test, but my fingers get tired.

So I suggest short option -w(for “with”) in analogy to cabal’s -w (short for –with-compiler) which does the respective GHC switch in the Cabal world.
I am looking forward to just have to type stack test -w stack-VER.yaml.
(Repetition (…stack…yaml…stack…yaml) is especially tiring to human neurons.)

4 Likes
4

Two possible alternative solutions are:

  1. as @andreasabel has explained, use different Stack project-level configuration files and swap between them with --stack-yaml; or
  2. use custom snapshot specifications and swap between them with --snapshot. An example of that approach is provided by Panty’s CI.
5

I think this derives the name of the argument from a single use case which doesn’t feel obvious in general.

My reading of TAOUCP is that -f might be justifiable:

-f

File (with argument). Very often used with an argument to specify an input (or, less frequently, output) file for programs that need to randomly access their input or output (so that redirection via < or > won’t suffice). The classic example is tar(1); others abound. It is also used to indicate that arguments normally taken from the command line should be taken from a file instead; see awk(1) and egrep(1) for classic examples. Compare -o below; often, -f is the input-side analog of -o.

Force (typically without argument). Force some operation (such as a file lock or unlock) that is normally performed conditionally. This is less common.

Daemons often use -f in a way that combines these two meanings, to force processing of a configuration file from a nondefault location. Examples: ssh(1), httpd(1), and many other daemons.

But I think -c for “config” might be ok (though you might have -c for “command” causing confusion) or -s.

My opinion isn’t hugely relevant here because I use cabal, but I hope it’s still useful.

1 Like
6

-f very often is short for --force, e.g. in rm -rf which I type daily. Also, -f would more plausible as abbreviation of the existing stack build options --fast, --flag, or --file-watch. In cabal build, -f passes a build flag.
I think imitating cabal is a good strategy, if in question, as this the tool closest to stack. This is why I suggest -w.

7

I’d use -c (short for config), but wouldn’t mind any other choice either.

8

Thank you everyone who provided input.

1 Like